Is your feature request related to a problem? Please describe.
bedrock_agentcore.tools ships first-class clients for two of the built-in tools:
browser_client.py provides BrowserClient
code_interpreter_client.py provides CodeInterpreterClient
Web Search has no equivalent, even though it is reachable today as a Gateway connector target. To run one search from Python a developer has to create a gateway, create a target whose targetConfiguration.mcp.connector.source.connectorId is web-search with the WebSearch operation enabled, attach a GATEWAY_IAM_ROLE credential provider, wait for the target to reach READY, and then call it over MCP with SigV4-signed requests. The comparable third-party search tools are an install and a key.
Describe the solution you'd like
Two additions, both following patterns that already exist in this repo.
-
src/bedrock_agentcore/tools/web_search_client.py with a WebSearchClient, shaped like the existing two clients in that package, so a search is one constructor and one call. The client owns the transport and the request signing, and keeps both as internal details that callers do not configure.
-
A create_web_search_target() helper on GatewayClient, directly analogous to the existing create_knowledge_base_target() at src/bedrock_agentcore/gateway/client.py. That method builds the connectorId: "bedrock-knowledge-bases" connector with enabled: ["Retrieve"] and a GATEWAY_IAM_ROLE credential provider, then delegates to create_gateway_target_and_wait(). The web search equivalent would build connectorId: "web-search" with enabled: ["WebSearch"] the same way. Generic target creation already works through create_gateway_target_and_wait(), so this is about a typed one-call helper rather than new capability.
The helper should also expose the filtering the connector supports. For reference, aws/agentcore-cli currently models only domain exclusion: WebSearchTranslatorInput in src/cli/operations/connectors/translators.ts has a single excludeDomains field and builds parameterValues.domainFilter = { exclude: [...] }. Domain inclusion is not exposed there.
Describe alternatives you've considered
Leaving each consumer to wire up Gateway and MCP itself. There are several that need the same thing: a Strands integration, a LangChain package, aws/agentcore-cli, the four framework examples in aws/mcp-proxy-for-aws, and the documentation. If each one builds its own path, every change to how a search is reached has to be repeated in all of them. One client in the SDK means it is done once.
Additional context
This repo already carries framework integrations for AgentCore capabilities under <capability>/integrations/strands/, and pyproject.toml has the strands-agents and langgraph extras wired for exactly that. A web search client here is the natural base for those.
Is your feature request related to a problem? Please describe.
bedrock_agentcore.toolsships first-class clients for two of the built-in tools:browser_client.pyprovidesBrowserClientcode_interpreter_client.pyprovidesCodeInterpreterClientWeb Search has no equivalent, even though it is reachable today as a Gateway connector target. To run one search from Python a developer has to create a gateway, create a target whose
targetConfiguration.mcp.connector.source.connectorIdisweb-searchwith theWebSearchoperation enabled, attach aGATEWAY_IAM_ROLEcredential provider, wait for the target to reach READY, and then call it over MCP with SigV4-signed requests. The comparable third-party search tools are an install and a key.Describe the solution you'd like
Two additions, both following patterns that already exist in this repo.
src/bedrock_agentcore/tools/web_search_client.pywith aWebSearchClient, shaped like the existing two clients in that package, so a search is one constructor and one call. The client owns the transport and the request signing, and keeps both as internal details that callers do not configure.A
create_web_search_target()helper onGatewayClient, directly analogous to the existingcreate_knowledge_base_target()atsrc/bedrock_agentcore/gateway/client.py. That method builds theconnectorId: "bedrock-knowledge-bases"connector withenabled: ["Retrieve"]and aGATEWAY_IAM_ROLEcredential provider, then delegates tocreate_gateway_target_and_wait(). The web search equivalent would buildconnectorId: "web-search"withenabled: ["WebSearch"]the same way. Generic target creation already works throughcreate_gateway_target_and_wait(), so this is about a typed one-call helper rather than new capability.The helper should also expose the filtering the connector supports. For reference,
aws/agentcore-clicurrently models only domain exclusion:WebSearchTranslatorInputinsrc/cli/operations/connectors/translators.tshas a singleexcludeDomainsfield and buildsparameterValues.domainFilter = { exclude: [...] }. Domain inclusion is not exposed there.Describe alternatives you've considered
Leaving each consumer to wire up Gateway and MCP itself. There are several that need the same thing: a Strands integration, a LangChain package,
aws/agentcore-cli, the four framework examples inaws/mcp-proxy-for-aws, and the documentation. If each one builds its own path, every change to how a search is reached has to be repeated in all of them. One client in the SDK means it is done once.Additional context
This repo already carries framework integrations for AgentCore capabilities under
<capability>/integrations/strands/, andpyproject.tomlhas thestrands-agentsandlanggraphextras wired for exactly that. A web search client here is the natural base for those.