The agent is burning tokens. The tool calls keep coming. Before blaming the protocol, the AWS developer advocate suggests looking at what you built—and whether a human can understand what happens next.
James Ward has a useful response to complaints that MCP wastes tokens: Show me the tools. If your agent needs 100 customer records and you gave it a tool that fetches exactly one, the ensuing parade of requests should not come as a shocking indictment of the protocol. You handed it a teaspoon and asked it to empty a five-gallon bucket.
Ward is cheerful about assigning responsibility and blame, including to himself. “I've built those terrible MCP servers,” he says. Getting an agent connected to something was exciting enough at first. As in, “It worked! It called a tool! Woot!” Post the demo, give the conference talk. Making the thing efficient could wait until later. Except later has arrived, now. Welcome to Ward’s World, where the goal is no longer MCP 101 or even MCP 201 but MCP 301 and beyond, a world where the protocol must handle big loads, long-running tasks, and complex enterprise applications. Or, as Ward might say, “Welcome to the MCP Matrix.”
Ward, an AWS developer advocate and member of the Agentic AI Foundation's technical committee, works daily on making AWS easier for agents and their humans to use. His upcoming AGNTCon + MCPCon North America session looks at what happens after the first successful MCP connection, including how to observe and improve agent interactions, reduce repeated tool calls, handle long-running tasks, and update servers without disrupting connected users.
Ward’s conversation with Demetrios Brinkmann reads half retrospective, half travelogue and half comedy act. Along the way, we get a story about rolling back an AWS documentation change, confessions about unreadable Python, and musings on the complexities of the Matrix.
MCP didn't make you fetch those customers one at a time
Ward's customer-record example captures a problem he sees frequently in posted beefs against MCP. An agent is asked to find customers emailed in the past 60 days. It identifies the customers, then repeatedly calls a tool that retrieves one customer by ID. The model keeps coming back into the loop. Tokens accumulate. The CFO is called. Blood pressure rises. Ad nauseam.
A simple fix? A tool that accepts a list of customer IDs could eliminate much of that traffic. But someone has to notice the pattern and build it. That sounds obvious until you look at what an MCP server can actually see. Individual requests arrive, but without a way to correlate them, the server operator may struggle to tell which belong to the same user task. A hundred successful calls can look perfectly healthy in isolation. Together, they might describe an agent taking the scenic route through a parking lot.
Ward wants builders to observe the whole journey. Which tools did the agent choose? What was it trying to accomplish? Could an aggregate tool turn 10 calls into one? Would a better description help the agent find that shortcut? Then test it. Run the task with the original tools and with the proposed improvement. Compare turns, tokens, and whether the agent actually takes the new route. A beautifully designed shortcut is of limited use if the model strolls past the entrance and gets lost.
This is the practical work behind Ward's larger ambition for agent experience. We can measure task completion, elapsed time, and token consumption, then use those measurements to improve the product. Getting connected was the opening act. Making sure users use agents effectively and with less toil and confusion is his North Star. Which is, actually, a lot harder than it sounds.
My matrix has 16,000 APIs. Harness that, friends.
There is, of course, a limit to solving everything with another carefully designed tool. Ward puts AWS's API surface at roughly 16,000 APIs. Exposing all of them as individual tools would be an impressive way to make discovery everybody else's problem and to spend vast amounts of tokens on tool discovery. Code mode offers another approach, but it brings its own problems.
To illustrate the conundrum, Ward describes an AWS MCP server that lets an agent write Python to sequence API calls. It gives the agent room to accomplish more complicated tasks without bouncing back to the model after every operation. But it also gives the human a new reading assignment to parse the code. Oh, joy.
Ward calls some of the generated Python “gobbledygook code.” He looks at it and struggles to understand what is about to happen. The interview briefly turns into a familiar engineering ritual: Looks good to me. Hope it works. Send it. Except this code may be operating on your cloud infrastructure. What could possibly go wrong? Roll back, roll back!
Ward is exploring a more constrained alternative: a low-code mode built around a domain-specific language, or DSL. The agent would describe a sequence of operations using a defined grammar and schema. That plan could be checked before execution, with useful feedback when it refers to a property that does not exist. The agent could repair the plan, and the human could review something more legible than an improvised Python program.
The motivation is concrete. In ordinary code mode, Ward says, an agent can reach step two of a 10-step operation and fail because it assumed a field existed. Catching that mistake before execution would save a failed run. Making the plan understandable would also give human approval more substance than a nervous click.
This remains an approach he is exploring. He is not announcing that AWS has solved it. But it is a promising question for MCP builders: How much freedom does the agent need, and how much structure would help both the agent and its supervisor?
Your helpful documentation looks suspicious
Even a modest improvement can have an unexpectedly exciting debut. Ward recounts an effort to add a short notice to AWS's Markdown documentation pointing readers toward the agent toolkit for AWS. The intent was straightforward: Here are tools that could make this task easier. In an early test, an agent classified the addition as a possible injection attack.
Good catch, in the sense that they had not shipped it yet. Less good for the helpful notice. Ward tried hundreds of wording variations against a small set of models and agent harnesses—the surrounding software that supplies instructions, tools, and the execution loop. Eventually the results looked encouraging. The agents were not flagging the snippet as malicious, distracting, or an advertisement. Sometimes they even recommended the toolkit. The team shipped it.
The next day, an email arrived: A user's agent was warning that AWS's Markdown documentation was attempting something potentially malicious. “Roll back, roll back,” Ward recalls. “Our matrix wasn't big enough.” (Note the pattern).
The anecdote explains why he does almost all his evaluation inside actual agent harnesses. A model's behavior depends on the environment around it. Change the harness, the model, the reasoning setting, the available tools, or the documentation it encounters, and you have another combination to test. Those combinations multiply quickly, as do the bills for running them.
The promise of measurable agent experience is both enticing and necessary. Alas, there is a copious amount of measurement required. Even the people building this infrastructure are discovering how many ways a seemingly helpful change can go sideways. The Matrix multiplication problem is real, friends. James has more thoughts but…you have to be in the room to get them.
Bring your MCP server questions to San Jose
Ward and Alexander Ioffe will present “Patterns for Shifting from MCP as a Basic API to MCP as Agent Integration Interface” at AGNTCon + MCPCon North America, October 22–23 in San Jose, California.
Ward is also looking forward to meeting AAIF working-group members in person. The questions from this interview—how agents find tools, how humans review actions, how builders know an improvement helped—are good reasons to get the people working on them into the same room.
Come with a server that works. Leave with ideas for making it work better. And perhaps a little less confidence in “looks good to me.” Use code COMMUNITY25 for 25% off registration. See you in San Jose.
Share
Author
