Low-level MCP wrappers make agents slow and unreliable because they expose APIs that were designed for programs, not language models.
2
Tools should contain more reasoning and return simple, useful outputs instead of forcing the main agent through long chains of API calls.
3
Wordware's agentic MCP toolbox lets teams turn workflows into reusable tools that can be called from agents such as Claude.
Summary
Robert Chandler argues that many MCP integrations expose too much low-level API detail to language models. A simple Slack request can turn into user searches, channel searches, repeated tool calls, and a misplaced message. Large JSON responses, pagination, authentication, and growing tool lists add noise and make agents slower, more expensive, and less reliable. His proposed fix is to make tools more agentic. A tool should be able to reason through a complete task and return a tidy result through a natural-language interface. Chandler demonstrates this with a competitor-analysis workflow in Wordware. The workflow gathers information from Twitter, writes a formatted report to Notion, and returns the page URL. He then adds it to a Wordware MCP toolbox and calls it from Claude. The example shows how a generic agent can delegate a specialised workflow instead of managing every API operation itself.
Agents promise real-world action, but ordinary integrations often fail
Chandler describes agents as systems that can act on a user's behalf with context about the user and their team. In practice, he says they are often slow, expensive, and unreliable. His Slack example starts with a simple request to message Philip about MCP. The integration lists users, searches channels, tries to send the message, and eventually posts in the general channel asking someone to tell Philip that MCP is awesome. The operation takes about five minutes and still fails to perform the requested action. Chandler uses this example to show that giving an agent access to a service does not mean it can use that service effectively.
Low-level API wrappers expose details that language models handle poorly
Chandler says many MCPs are low-level wrappers around APIs built for deterministic programs rather than language models. Those APIs often return large JSON blobs, which add irrelevant information to the model's context. The tools also tend to have tiny scopes because they wrap individual functions. A program can compose those functions into a fixed sequence, but an agent has to keep reasoning across every call and every output. This creates context pollution and makes the agent responsible for managing implementation details that could have been hidden inside a higher-level workflow.
Pagination and authentication add more work around the actual task
The problem grows when an API uses pagination. The model may need to keep calling the service until it finds the data it needs, which lengthens the request chain and fills the context window with intermediate results. Chandler also mentions authentication as a practical obstacle. Hosted MCPs make it easier, but teams may still need API keys, bots, or other setup. These concerns combine with the number of available tools. Adding Slack can bring eight tools, while adding Notion can bring about twenty more, giving the agent more instructions and more possible sources of confusion.
A tool should have enough agency to complete a meaningful task
Chandler's solution is to add more agency inside the tools rather than exposing many small functions. He compares the small-tool approach to a T-Rex holding a tiny spanner and to Inspector Gadget carrying a thousand tools. His preferred model is a team of specialists, where different agents handle different tasks and a main agent delegates to them. The boundary between an agent and a tool becomes flexible: an agent can be a tool for another agent. Each specialised component can accept a simple natural-language request and return a reliable, reusable, high-quality result.
A competitor-analysis workflow can hide its integrations behind one tool
Chandler demonstrates the approach with a competitor-analysis workflow in Wordware. The workflow uses a Twitter scraping tool, but the important part is the detailed description of what the analysis should cover. It can include information about the company and the differences the user wants to investigate. The workflow performs the analysis, writes the result to Notion, and returns the URL. This packages the reasoning and the integrations into a single task-oriented interface. The calling agent does not need to search Twitter, manage the analysis steps, format the document, and locate the final page separately.
An MCP toolbox lets agents call specialised Wordware workflows
Chandler adds the competitor-analysis workflow to a Wordware MCP toolbox and connects the toolbox to Claude. He asks Claude to create a competitor analysis for Anthropic. Claude invokes the Wordware tool, with the user able to allow the call once or always. The completed workflow produces a formatted Notion page based on Anthropic's tweets, including observations about the company's tweeting style. Because the result is stored in Notion, it is available outside the chat and can be found again through the returned link.
Grouped agentic tools reduce the burden on the main agent
Chandler says Wordware's toolbox can contain multiple tools that are related or completely different. Users can switch toolboxes on or off for different tasks. In his view, this creates a highly reliable, repeatable, and aligned tool for a specific job while leaving the generic agent free to delegate. The main agent does not need to perform every low-level operation itself. Chandler compares this arrangement to specialists in a company, where people with different skills take responsibility for particular tasks. He closes by saying that these flows can be built with Wordware or with other systems that support agentic MCPs.
"We managed to build a highly reliable, highly repeatable, and highly aligned tool that allows our generic agent to be very specific and very powerful for doing that task that we wanted it to do."06:10
Who should watch
You are exposing Slack, Notion, or other API functions directly to an LLM and the agent keeps getting lost in intermediate calls.
You want to package a multi-step workflow into a single natural-language tool that another agent can call.
You are building MCP integrations and need a concrete example of hiding scraping, analysis, formatting, and storage behind one task-focused interface.
