DEV Community: Guilherme Dalla Rosa

An agent with hundreds of tools

Guilherme Dalla Rosa — Tue, 06 Oct 2026 14:38:46 +0000

Tools are what turned language models into agents, and the Model Context Protocol (MCP) made plugging them in cheap enough that nobody stops at three. Every system the agent has to touch adds its own set, each with dozens of endpoints, so an agent that started with three tools ends up with far more in front of it than any task needs. The trouble is that every one of those definitions is loaded into the context window up front. A good chunk of the context is gone before the first message arrives. And with so many tools that look alike, the model picks the wrong one more often than you'd expect. Nothing fails outright, but the agent takes longer, costs more per turn and, every so often, does the wrong thing without a single error in the logs.

Connecting that many tools isn't a wiring problem, it's a context problem. What the model sees and when it sees it decides whether the agent works. That decision belongs to the harness, the loop and the tooling around the model, and it's yours whichever model sits inside it. In the pattern that has settled for this, called progressive disclosure, the model never sees the full catalogue.

Where all those tools come from

Most of those tools come from a habit that goes back to the first MCP servers, when the usual way to build one was to map every endpoint of an API to its own tool. That's how a single integration turns into a few dozen tools before anyone has asked whether the agent needs them. Neon's recent video MCP Just Got a Whole Lot Better walks through how that habit came about and what Neon changed on their own server as a result, so it's a good place to start if you want the server-side view.

The tool definitions are billed on every turn, at a discount if prompt caching is on. The MCP client best practices draw the difference between loading them all and fetching them on demand:

Source: MCP client best practices, from the Model Context Protocol documentation.

The wrong tool is the part of the bill you can't see, and Anthropic's tool search documentation says Claude's ability to pick the right tool degrades once you exceed 30 to 50 available tools, a line that two integrations of a few dozen tools each already cross. The post that introduced advanced tool use measured the difference tool search makes on Anthropic's own MCP evaluations:

Model	Without tool search	With tool search
Opus 4	49%	74%
Opus 4.5	79.5%	88.1%

Source: Introducing advanced tool use on the Claude Developer Platform, Anthropic.

The costs don't stop once the agent starts working, because every tool result lands in the context and the model reads past pages of output on every turn. The model gets less reliable as its input grows, even on simple tasks, which Chroma's Context Rot report measured across 18 models. In an agent, that's the rule you agreed ten turns earlier being forgotten, and I've seen it happen with a much smaller set of tools.

Three tools instead of all of them

Progressive disclosure replaces the catalogue with three meta-tools:

search takes a plain description of what the model needs and returns the matching names, each with a one-line description
get_definition returns the full schema of a single tool
invoke calls it and returns the result

Only the definitions the model asked for ever enter the context.

The MCP guide calls the pattern progressive discovery, a name worth knowing before you search for it, and recommends it for clients that connect to many servers.

Progressive disclosure only pays off once the tool definitions take a share of the context window worth recovering. Below that, or when every tool is used on every request, plain tool calling is the better fit. The guide gives 1% to 5% of the window as an example of where to put the line, while Anthropic draws its own at 10 tools or 10,000 tokens of definitions.

Once the model asks for something, somebody has to decide what a match is, and the guide lists four ways to do it:

Keyword matching, BM25 or a regex, which is simple and works well when tool names and descriptions are descriptive
Embeddings over the tool descriptions, which handle synonyms and phrasing the keywords miss
A small, fast model as a sub-agent that picks the tools for the task, which usually works well but can cost more
A hybrid, scoring across keyword and embedding rankings, or switching strategy by use case

The four above are what you build when your provider doesn't ship a tool search of its own, or when you need your own ranking.

One caveat: a search can come back empty, and nothing in the pattern tells the agent what to do about it. Anthropic's tool search returns an empty list rather than an error when nothing matches, so the model does what models do and tries again with a different query, and then again. The stop has to come from the harness, which in Strands means the limits you pass with each invocation to cap the number of turns and the total tokens a run can use. What happens when the budget runs out is your decision, whether that's a partial answer, a plain "I can't do that" or a hand-off to a person.

Where the search can live

These three tools can run on the server, on a gateway in front of every server or on the client that runs the loop, and what changes between them is simply who holds the index.

On the server

A server can trade one tool per endpoint for those three. Neon's video calls this a layered tool call and describes how a lot of MCP servers moved to it. AWS built its own AWS API MCP Server this way, and it covers the whole API with two tools, suggest_aws_commands to search and call_aws to run the command it found:

from fastmcp import Context, FastMCP
from typing import Any

server = FastMCP(name='AWS-API-MCP')

@server.tool(name='suggest_aws_commands')  
async def suggest_aws_commands(query: str, ctx: Context) -> dict[str, Any]:
    """Suggest AWS CLI commands based on the provided query."""
    with get_requests_session() as session:
        response = session.post(
            ENDPOINT_SUGGEST_AWS_COMMANDS,
            json={'query': query},
            timeout=30,
        )
        response.raise_for_status()
        return response.json()

@server.tool(name='call_aws') 
async def call_aws(cli_command: str, ctx: Context) -> CallAWSResponse:
    """Call AWS with the given CLI command and return the result as a dictionary."""
    # call_aws_helper validates the command and applies the security policy
    response = await call_aws_helper(cli_command, ctx, None, None)
    return CallAWSResponse(cli_command=cli_command, response=response)

if __name__ == '__main__':
    main()  # loads the read-only operations index, then server.run()

Adapted from AWS API MCP Server, AWS Labs.

The search itself isn't in the code, because suggest_aws_commands sends the query to a service AWS hosts, which returns the most likely CLI commands with their descriptions and parameters, so the search and the definition arrive in one step. AWS has since marked the server as entering end of development and points users to its managed AWS MCP Server instead.

The limit shows up when there are ten servers built the same way, because the agent is then choosing between ten indexes and ten sets of meta-tools. To be fair, Neon's own counter, which Andre Landgraf's post Give your agent Neon tools walks through, is that a tool bundling three calls into one workflow saves the agent from making the same mistakes every time, the way an SDK wraps raw endpoints in convenience methods. Those workflow tools still belong on the server.

On the gateway

A gateway sits between the agent and every server, so there is one connection and one index whatever is behind it. Solo Enterprise for agentgateway does it with two meta-tools, get_tool and invoke_tool, in the setup that Michael Levan, AI Architect at Solo.io, walks through in his post MCP Progressive Disclosure: Save Tokens, Retrieve Schemas. On AWS, AgentCore Gateway ships the search as a built-in tool, x_amz_bedrock_agentcore_search, which has to be enabled when the gateway is created and can't be turned on afterwards. In Strands, AWS ships a plugin for that search in its bedrock-agentcore package:

from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client
from strands import Agent
from strands.tools.mcp import MCPClient
from bedrock_agentcore.gateway.integrations.strands.plugins import AgentCoreToolSearchPlugin

mcp_client = MCPClient(lambda: aws_iam_streamablehttp_client(
    endpoint="https://<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp",
    aws_region="us-east-1",
    aws_service="bedrock-agentcore",
))

with mcp_client:
    agent = Agent(plugins=[AgentCoreToolSearchPlugin(mcp_client=mcp_client)])
    agent("Find me afternoon flights to New York")

From Amazon AgentCore Tool Search, Strands Agents docs.

Before each request, the plugin has the model sum up in one line what the user wants, searches the gateway with that line and loads only the tools that come back, so the model never searches for itself. The price is an extra model call per request and one more hop on every tool call.

On the client

The guide itself is written for the client, where the host lists the tools from every server once, keeps the definitions on its side and exposes the search, so the servers stay as they are. Strands 1.57 added a coarser version of the pattern as a vended tool, the MCP router:

from strands import Agent
from strands.vended_tools import make_mcp_router

mcp_router = make_mcp_router(
    servers={
        "orders": {"url": "https://orders.example.com/mcp"},
        "billing": {"url": "https://billing.example.com/mcp"},
    },
    max_connections=5,
)
# Nothing connects yet. The model sees one tool, mcp_router, whose
# description ends "Permitted server names: 'billing', 'orders'."
agent = Agent(tools=[mcp_router])
agent("Which orders shipped late this week?")

Adapted from MCP Router, Strands Agents docs.

The model connects to a server by name, lists its tools and calls one, all through that same tool, so list_tools does the job of get_definition for a whole server and call_tool is invoke. The router has no search, which leaves the model picking a server by its name alone and reading every definition on it. A search_tools tool and deferred loading are on the Strands roadmap, in its tool selection design.

Anthropic's tool search and OpenAI's are the native version of the full pattern, where you add the provider's search tool to the tools array and mark the others defer_loading. On Bedrock, Anthropic's version works through the InvokeModel API but not Converse, which Strands uses, so there the search on top of the router is still yours to build.

The catch on the client is the prompt cache, because most providers cache the prompt prefix with the tools array in it, so adding a definition mid-conversation invalidates it and the miss can cost more than the definitions you saved. Of the guide's two fixes, the router takes the one that sends every call through a single stable tool so the array never changes, and the native versions take the other, appending what the search finds after the cached prefix.

Code mode

Search cuts the definitions the model sees, but each call still makes a round trip through the model. In code mode, the model writes a script that chains the calls, the script runs in a sandbox and only what it prints comes back. Kenton Varda and Sunil Pai at Cloudflare named it Code Mode, and the guide calls it programmatic tool calling. Their colleague Matt Carey's follow-up pairs it with search to put more than 2,500 Cloudflare endpoints behind two tools.

In Strands, the strands-harness package ships it as a built-in tool, programmatic_tool_caller, which turns every other tool the agent has into a function the script can call. With the gateway search plugin loading the tools first, the model calls them from one script:

from strands_harness import create_harness
from bedrock_agentcore.gateway.integrations.strands.plugins import AgentCoreToolSearchPlugin

# mcp_client: an MCPClient for the AgentCore Gateway
with mcp_client:
    agent = create_harness(
        plugins=[AgentCoreToolSearchPlugin(mcp_client=mcp_client)],
        builtin_tools={"*": False, "programmatic_tool_caller": {"timeout": 60}},
    )
    agent("Which team members exceeded their Q3 travel budget?")

# The model sends one script, such as:
#   import asyncio, json
#   team = await hr___get_team_members(department="engineering")
#   expenses = await asyncio.gather(*[
#       hr___get_expenses(user_id=m["id"], quarter="Q3") for m in team
#   ])
#   ...  # compare each total with its budget, inside the sandbox
#   print(json.dumps(exceeded))

Adapted from Add tools and instructions, Strands Agents docs, with the model's script from Introducing advanced tool use on the Claude Developer Platform, Anthropic.

The script runs in Monty, Pydantic's Python interpreter written in Rust, with no access to the filesystem, the network or the environment, so the credentials stay with the host and the gateway. On the server side, the managed AWS MCP Server offers the same idea as aws___run_script, where the script reaches only the AWS APIs and IAM checks each call.

Code mode opens a code execution surface that's now yours to run. The guide is explicit that approving a script doesn't approve every call it makes, so in strands-harness each call still goes through the agent's hooks and policies, then through the gateway's own authorisation. A call that needs a person's approval fails, though, because the package can't pause a running script to ask for it.

Where to put it

In my opinion, the search belongs in the harness you own, whether that's the client or the gateway. Jiquan Ngiam, co-founder and CEO of MintMCP, which sells an MCP gateway, is blunter about the servers, writing that "progressive tool disclosure should be done by the agent, not as an MCP server tool".

A small API with a handful of endpoints is still fine with one tool per endpoint. To be fair, a single API as large as Cloudflare's or AWS's is where Matt's case for putting code mode on the server makes sense. As always, it depends on your requirements. If you want to go further, the Strands docs on programmatic tool calling explain how code mode runs in the harness you own.

Aurora DSQL now supports foreign keys. What else?

Guilherme Dalla Rosa — Mon, 07 Sep 2026 10:35:29 +0000

AWS recently announced that Amazon Aurora DSQL now supports foreign key constraints. If you've been following DSQL since the preview, you know why this one matters.

Aurora DSQL is the serverless, distributed database from AWS that speaks PostgreSQL: no instances to size, scaling to zero when idle, and multi-region clusters where you write to any region and read a consistent answer from all of them. Instead of locking rows, it detects conflicts at commit time and asks the loser to retry. I covered all of that in my talk What DSQL? Rethinking SQL for the Serverless, Distributed Age at AWS Community Summit Manchester, and one of the limitations I highlighted there was the lack of foreign keys, a potential blocker for some use cases.

The syntax is the one you already know from PostgreSQL: a column-level REFERENCES or a table-level FOREIGN KEY, with the same match types, the same five referential actions and the same deferrable options, so the DDL you wrote for PostgreSQL should run as it is:

CREATE TABLE customers (
  id uuid PRIMARY KEY,
  name text NOT NULL
);

CREATE TABLE orders (
  id uuid PRIMARY KEY,
  customer_id uuid NOT NULL REFERENCES customers (id) ON DELETE RESTRICT,
  total numeric(18,2) NOT NULL
);

The one DSQL-specific detail is adding a constraint to a table that already has rows. Where PostgreSQL would scan the table there and then, DSQL has you add the constraint as NOT VALID and validate the existing data afterwards, as an asynchronous job you can follow in the sys.jobs system view, the same way you follow an asynchronous index build:

ALTER TABLE orders
  ADD CONSTRAINT orders_customer_fk
  FOREIGN KEY (customer_id) REFERENCES customers (id) NOT VALID;

What changes in practice is who enforces the relationship: from now on the database refuses the write, and a schema you carry over from a PostgreSQL project needs fewer exceptions. One caveat: the foreign key documentation is clear that every write to a referenced or referencing table costs extra reads. A CASCADE also counts toward the 3,000-row limit of a transaction, so a delete that fans out into thousands of child rows still has to be chunked.

To be fair, not everyone wants foreign key constraints in the first place. PlanetScale's guide to operating without foreign key constraints explains why they don't recommend them. Constraints mean more locking under high concurrency, column types you can no longer change, more complex schema refactors and rules that are hard to maintain once data is split across servers.

Their advice is to keep the relationships in your model and enforce them in the application, which is what most of us had been doing on DynamoDB anyway. DSQL's implementation avoids the locking part of that list, and the rest turns into the extra reads and the row limit above. Nice to have the option, and still worth measuring before you turn it on everywhere.

Then, last month at AWS Community Day Singapore, I watched Yuuki Yamashita's talk Distributed Transactions Under Fire: Building a Zero-Oversell Flash Sale Platform with Amazon Aurora DSQL. The problem is familiar to anyone in e-commerce: a limited drop lasts 30 seconds, race conditions cause oversells and provisioning for that peak means paying for it all month. So he built a flash sale on Lambda and DSQL where two buyers race for the last item and the first to commit wins.

His demo put 100 concurrent buyers against 10 items and came out with 10 orders and zero oversells. The honest part of the talk was what broke on the way. Connections cached across Lambda invocations outlived the 15-minute IAM token, and the retries themselves tripled the load until backoff with jitter and a cap of three attempts turned the storm into a clean sold-out. It's the kind of real-world lesson I look for, and it left me wondering what else had improved in the DSQL world since my talk. So here's what I found.

What else has improved

Let's start with the one I was hoping for when I first looked at DSQL: change data capture (CDC). DynamoDB Streams has spoilt me: the database propagates every change to a stream, and the rest of the event-driven architecture hangs off it without the application having to publish anything. With a traditional relational database you end up building the transactional outbox pattern instead, writing the event in the same transaction as the data, polling the outbox table and pushing it to the bus, and keeping the two in step.

CDC now does that for you: inserts, updates and deletes go to Kinesis Data Streams as change events, and from there to Lambda, or to S3, Redshift and OpenSearch through Firehose. In my opinion this is as big an announcement as the foreign keys, because it makes the case for DSQL as a replacement for DynamoDB in event-driven applications, with SQL on top. One caveat: delivery is at least once, so the consumer still has to deduplicate and order the records, and the stream is billed in DPUs by the volume it captures. If you want to try it, Vijay Karumajji's getting started guide walks through the setup, from the Kinesis stream and the IAM role to the first events.

The rest of the engine changes closed several other items on my slide, and the release notes are the place to follow them:

Multi-region is no longer a US-only story. Multi-region clusters run in 16 regions across three region sets, with Frankfurt, Ireland, London, Paris, Spain and Stockholm on the European side, and single-region clusters are available in 20 regions. A cluster still has to stay inside one region set.
Identity columns and sequences are in, with a cache you have to set explicitly and values that can arrive out of order across sessions.
JSON and JSONB are supported, another item from the slide.
Schema changes got easier: DROP COLUMN, constraints added as NOT VALID and validated later, indexes on expressions and extended statistics are all in.
Clusters now create in seconds instead of minutes, and storage goes up to 256 TiB. What hasn't moved is the other half of the slide, and the migration guide is the honest place to read it. No triggers, no PL/pgSQL, no temporary tables, no extensions (so no pgvector and no PostGIS), one database per cluster, and 3,000 rows and 5 minutes per transaction. Those aren't gaps waiting to be filled, they're the design, and the examples below are mostly about building around them.

What the community learned

The lesson that repeats across every story I read is that retries are a design decision, not an error handler. Marc Bowes, who works on DSQL, shows in avoid hot keys why a single counter row that every transaction updates is the classic mistake, and why appending rows and summing them is the shape that scales. Fernando Azevedo's field notes on multi-region add the other rule of thumb: every commit in a multi-region cluster pays the round trip between the regions, so an abort rate creeping up is a design smell before it's a database problem. For the bigger picture, Marc Brooker's DSQL: Simplifying Architectures makes the case for an active-active setup with no failover logic and no leader election. The team also published the paper, for anyone who wants the full story of how it works.

Use cases and examples

A few references worth keeping, from talks and production stories to sample apps:

Vadym Kazulkin, AWS Serverless Hero, has been covering DSQL from the Java side on stage and in writing for a while. His seven-part series Serverless applications on AWS with Lambda using Java 25, API Gateway and Aurora DSQL goes from the sample application to SnapStart with DSQL request priming and GraalVM Native Image, with the code on GitHub, and his re:Invent session Build modern applications with Amazon Aurora DSQL has the latency numbers for an ordering app on single-region and multi-region clusters.
Darryl Ruggles' multi-region Kabob Store, an e-commerce sample with the Terraform to reproduce it, and his practical guide to Aurora DSQL.
The aurora-dsql-samples repository from AWS, with client examples for most languages and ORMs, a booking API with the retry logic in place and a sample AI agent that uses DSQL as its store.
The AWS Database Blog on DSQL for gaming, for financial transactions and as the store behind an AI agent on Bedrock AgentCore.

The Top Serverless Announcements from AWS re:Invent 2023

Guilherme Dalla Rosa — Mon, 04 Dec 2023 19:15:30 +0000

With numerous AI-related announcements, this year's re:Invent marked a significant shift towards AI. The standout was Amazon Q, which was revealed during the keynote. Amazon Q, AWS's counterpart to ChatGPT, integrates into the AWS console, AWS documentation pages, and IDEs via the VS Code plugin, AWS Toolkit. Uniquely trained on AWS documentation and immune to the restrictions of ai.txt, Amazon Q promises more current answers than ChatGPT.

Steering away from the AI buzz (if that's even possible), let's dive into the serverless realm and check groundbreaking announcements that were made and how they might revolutionise our tech toolkit.

ElastiCache "serverless"

The launch of Amazon ElastiCache Serverless marks a significant stride in AWS's serverless offerings. This new service addresses many limitations of the traditional ElastiCache, making it more user-friendly and fitting the serverless model more closely.

The key highlights include:

Simplified Operation: No need to choose instance types or worry about bandwidth and TPS limits.
Native API Support: Supports Memcache and Redis APIs, easing migration from server-based setups.
Multi-AZ and VPC Support: Offers built-in high availability and works with VPCs from day one.
Eliminated Autoscaling Groups: Autoscaling is more straightforward, although it can take time to scale up during sudden spikes.
Pay-per-use Pricing: A move towards a dynamic pricing strategy aligned with serverless computing principles.

While Amazon ElastiCache Serverless introduces several improvements over its predecessors, it has sparked mixed feelings within the tech community, particularly concerning its pricing and its serverless credentials.

The pricing, notably high, includes a minimum charge of $90 per month for even minimal data storage. For instance, storing just slightly over 1 GB can cost $180 monthly!. This contrasts with on-demand instances, where comparable storage is significantly cheaper.

Operational concerns also come into play. The requirement to run Lambda functions within a VPC leads to additional VPC-related expenses. Additionally, the scaling capability, which only allows doubling capacity every 10 minutes, is perceived as sluggish. This combination of high costs and operational limitations has sparked debates about the service's practicality and affordability, particularly for sporadic usage scenarios.

Lambda Scales 12x Faster

AWS Lambda has revolutionised its burst concurrency limits, significantly enhancing its scaling capabilities. Previously constrained by a region-wide burst limit of 500–3000 and a slow refill rate, Lambda now allows each function to burst to 1000 concurrent executions instantly. What's more, this limit increases by 1000 every 10 seconds, with each function scaling independently.

This change is a game-changer for scenarios with sudden traffic spikes, like flash sales. For instance, with an average request time of 100ms, a single execution can handle 10 requests per second. So, you can now burst to 10,000 requests per second per endpoint, with an additional 10,000 every 10 seconds, up to your account-level limit.

This level of scalability introduces new considerations, especially around system bottlenecks. For example, API Gateway, with its default limit of 10,000 requests per second, could now become a throttle point.

Step Functions Enhancements

AWS Step Functions has introduced several significant updates:

Public HTTP Endpoints: Step Functions can now directly call any public APIs, eliminating the need for Lambda or API Gateway proxies. They utilise existing HTTP connections from EventBridge.
Testing Individual States: You can test individual states in your state machine without full execution. This is facilitated by the new TestState endpoint, enabling programmatic testing.
Integration with AWS App Composer: Step Functions now integrates with AWS App Composer, allowing for easy inclusion and editing of state machines within stacks.
Optimised Integration with Bedrock: Enhanced support for AI app development, though Lambda remains preferable for streaming responses, especially for frontend applications.

SQS FIFO Throughput Massive Increase

AWS has dramatically increased the throughput for SQS FIFO, now enabling processing of up to 70,000 messages per second in high throughput mode. This enhancement marks a significant leap in handling large volumes of messages efficiently, catering to more demanding and high-traffic applications.

Aurora Limitless Database

Amazon Aurora has launched the Aurora Limitless Database, a significant upgrade allowing clusters to scale up to millions of write transactions per second and manage petabytes of data. While most users may not require this extreme level of scalability, the technical achievement is impressive and noteworthy.

Final thoughts

re:Invent 2023 showcased an array of remarkable advancements, particularly in the Serverless domain. From the significant scaling improvements in Lambda and SQS FIFO to the innovative features in Step Functions and the technical prowess of Aurora Limitless, AWS is pushing the boundaries of what's possible in cloud computing. While some offerings, like ElastiCache Serverless, sparked debate over pricing and operational aspects, the overall direction is clear: AWS is committed to providing more robust, scalable, and efficient solutions, driving the future of Serverless computing forward. As we embrace these changes, it's exciting to ponder how they will shape our technological landscape in the coming years.