AWS has launched a standalone Web Search API for Amazon Bedrock AgentCore, enabling developers to retrieve ranked web results directly via AWS SDKs or the CLI without provisioning an AgentCore Gateway. By utilizing IAM-based authentication and SigV4 signing, this update allows applications like monitoring dashboards or data pipelines to treat search as a standard API dependency. While this simplifies architecture by removing the need for Model Context Protocol layers, developers must manually manage domain filtering and be mindful of differing default result counts and date-handling logic compared to the existing gateway connector.
AWS has added a standalone Web Search API to Amazon Bedrock AgentCore, letting developers retrieve ranked web results without first creating an AgentCore Gateway or search target. Applications call the InvokeWebSearch operation through AWS SDKs or the AWS CLI using their existing AWS credentials.
The practical change is small but useful: a dashboard, monitoring service or custom agent loop can now treat web search as an ordinary AWS API dependency. Teams no longer need to introduce a Model Context Protocol (MCP) connection solely to retrieve search results.
Choosing the direct API still involves trade-offs. AWS’s documentation identifies differences in authentication, policy enforcement, default result counts and date handling that matter when moving an existing integration.
What the Direct API Removes
Previously, AgentCore’s web search was accessed through AgentCore Gateway. Developers created a gateway, added a web search target and called the tool from an MCP client. The standalone API exposes search directly on the bedrock-agentcore data plane, eliminating those provisioning steps.
Requests use AWS Signature Version 4, or SigV4. AWS SDKs and the CLI sign requests using the caller’s AWS credentials, so applications do not need a separate search API key. The caller still needs an IAM identity with permission to invoke the service. “No resources to create” means no search-specific resources, not permission-free access. AWS’s technical announcement describes that request flow.
Each response contains ranked results from an Amazon-operated web index:
A text extract for every result.
A page title and URL when available.
A publication time when available.
AWS says queries are served inside AWS and are not sent to a third-party search engine. The API also accepts domain and publication-time filters.
For an application that already owns its orchestration, this removes a deployment dependency. A fact-checking pipeline can retrieve candidate sources; a dashboard can find product announcements; an agent loop can pass extracts to a model. None of those patterns inherently requires an MCP tool endpoint.
My view is that this is the strongest reason for the update: teams can add search without also adopting another tool-access layer. AWS still recommends Gateway for most agentic workloads, particularly when agents need access to multiple tools through one endpoint.
Making a Search Request
The caller needs the IAM action bedrock-agentcore:InvokeWebSearch on the AWS-managed search tool. For US West (Oregon), AWS’s example uses this resource:
AWS says the action and resource are the same ones used by a gateway’s service role for web search, allowing the same permission policy to support either route. The identity making the call must have that permission attached through the appropriate IAM configuration.
With credentials and permission in place, a Python request follows this pattern:
This example requests up to 10 ranked results from the Oregon endpoint and prints the returned results. It illustrates the documented Boto3 operation; it is not a test run. The operation name and parameters come from the AWS launch walkthrough.
Applications should handle missing titles, URLs and publication timestamps. Those fields depend on what the index has available. A rendering layer that assumes every result has all three could fail even when the search request succeeds.
The response is search material, not a generated answer. Your application decides which extracts to use, whether to retrieve additional context and how to present supporting sources.
Direct API vs. Gateway: The Documented Differences
Both routes provide AgentCore web search, but their interfaces and controls differ. The developer guide’s comparison makes the choice more concrete than a general preference for fewer components.
Detail
Standalone Web Search API
Gateway Web Search Connector
Calling interface
AWS SDK or CLI call to the data plane
MCP tool call through a gateway
Caller authorization
IAM only
Can also authorize callers with JWT
Domain filtering
Supplied in each request
Can also apply target-level domain lists hidden from the calling agent
Search-text parameter
searchQuery
query
Default result count
Up to 25
Up to 10
Publication range fields
publishedAfter, publishedBefore
from, to
AWS GovCloud (US-West)
Unavailable
Available
The authentication distinction matters for existing applications. An AWS-hosted service that already uses IAM roles has a straightforward direct path. A platform exposing tools to clients authenticated with JSON Web Tokens may find the gateway’s authorization model more suitable.
Domain policy is the more consequential governance difference. The connector can apply a target-level domain list without exposing it to the calling agent. The direct API takes its domain filter from each request.
I’d keep the gateway when several agents must share a centrally applied source policy. A direct integration can enforce a similar rule in application code, but that enforcement becomes the application’s responsibility. Passing a domain list in one request is different from configuring a target that applies it across requests.
Gateway also combines web search with other tools and provides authentication handling, semantic tool selection and optional MCP sessions, according to AWS. Those capabilities can justify the extra setup when search is one part of a broader tool environment.
Two Migration Details Worth Checking
Set the Result Count Explicitly
Leaving out maxResults changes behavior between the two interfaces: the API returns up to 25 results by default, while the MCP tool returns up to 10.
A migration that preserves only the search text can therefore send more extracts into downstream processing. If an application feeds every extract to a language model, that can increase its model input. This is a practical inference from the documented defaults, not a measured latency or cost result.
Setting maxResults explicitly makes the application’s intent clearer and avoids an accidental change in how much material it processes.
Use Explicit Timestamps for Date Filters
Both interfaces treat publication-range boundaries as inclusive, but date-only values behave differently.
For the MCP connector, a to date includes that entire day. With the API, AWS SDKs and the CLI send a date-only publishedBefore value as midnight UTC at the start of that day.
For example, an API upper bound of 2026-11-10 becomes midnight at the beginning of November 10, not the end. Copying a connector filter directly could therefore exclude most of the intended final day.
For monitoring jobs and reproducible research pipelines, I’d use explicit UTC timestamps and document the boundary convention. The developer guide spells out this difference, which is easy to miss during an otherwise simple integration change.
Pricing, Regions and Operational Guardrails
AWS lists the same search-query rate for both routes: $7 per 1,000 queries. Direct API calls incur no gateway charges. At that published rate, 100,000 queries would cost $700 in search charges, before any separate application, model, networking or other applicable costs. This is arithmetic based on AWS’s price, not a measured deployment bill. The launch notice supplies the rate.
The API is documented as available in six Regions:
US East (N. Virginia), us-east-1
US East (Ohio), us-east-2
US West (Oregon), us-west-2
Asia Pacific (Sydney), ap-southeast-2
Asia Pacific (Tokyo), ap-northeast-1
Europe (Ireland), eu-west-1
The default quota is 10 requests per second per account, per Region. AWS says customers can request an increase through AWS Support. PrivateLink supports calls from a VPC, and requests can be logged as CloudTrail data events. Prices, regional availability and quotas should be checked in current AWS documentation before production deployment.
The developer guide’s acceptable-use terms also affect application design. Outputs shown to end users that use search results must retain and display the supplied source citations and links. Bulk extraction, storage or reproduction of search-result content is prohibited, as is building or populating a competing index or database.
That makes citation handling an implementation requirement. A fact-checking dashboard needs to preserve source attribution through processing and rendering, not discard it after creating a summary.
GovCloud users face a simpler decision: the standalone API is unavailable in AWS GovCloud (US-West), while the connector is supported there. For those deployments, removing the gateway is not currently an option.
Frequently Asked Questions
3 questions
1
Can Non-Agent Applications Use the API?
Yes. AWS explicitly supports applications and data pipelines, including dashboards, monitoring systems and fact-checking workflows. An agent runtime is not required.
2
Does the API Generate an Answer?
It returns ranked search results with text extracts and available metadata. Answer generation and source selection remain part of the calling application.
3
Does the Standalone API Replace Gateway?
No. Gateway remains useful for MCP tool access, shared policies and broader tool management. The direct API serves code that wants search results without that additional infrastructure.
