If you’re building an agentic product, especially in a large tech company, you’ll likely need to integrate with multiple partner teams that offer unique context or actions that enhance your agent’s performance. These integrations are most commonly vended as MCP tools. These tools come in vastly different granularities. On one end of the spectrum are deterministic, fast, “do one thing well” functions, while the other end represents agents-as-tools that handle complex queries and a larger set of use cases by orchestrating multiple tool calls and reasoning steps until the assigned task is completed. This blog post argues that partner teams vending AI capabilities should give power back to their clients: offer flexibility so agent builders can decide their level of integration.

Make it fast rather than general or powerful, because then the client can program the function it wants. Slow, powerful operations force the client who doesn’t want the power to pay more for the basic function. Usually it turns out that the powerful operation is not the right one. – Butler Lampson, Hints and Principles for Computer System Design

The key problem with teams vending only an AI agent as the integration point is the insight from Butler Lampson’s quote above: you’re forcing clients to pay more when they only want a subset of the functionality. Let’s explore some of the specific challenges of exposing only agents to clients.

Context clash. When your agent’s scope overlaps with the client’s scope, conflicts are inevitable. The client likely already has tool specifications that overlap with your agent’s functionality, forcing them to modify their existing tool descriptions and system prompt to disambiguate when to use your agent versus their existing toolset. As noted in the analysis of how long contexts fail: “Agents assemble context from documents, tool calls, and from other models tasked with subproblems. All of this context, pulled from diverse sources, has the potential to disagree with itself. Further, when you connect to MCP tools you didn’t create there’s a greater chance their descriptions and instructions clash with the rest of your prompt.”

Latency. If the client only needs a handful of tools present within your agent, they’re forced to invoke your entire agent abstraction. At best, this adds one unnecessary LLM call where the client’s LLM determines it needs to use your agent, then your agent’s LLM arrives at the same conclusion about which specific tools to invoke. At worst, your agent performs few additional LLM calls. This creates unnecessary delays and a worse customer experience.

Cost. A corollary of the explanation above is that the cost of unnecessary LLM inference calls either gets passed to the client’s customers or eats into their margins.

The alternative is for partner teams to expose both options. For example, you can expose an MCP server that includes both granular functions and coarse agents that orchestrate those tools. When there’s clear separation between your agent’s scope and the client’s existing capabilities, and the queries are complex enough to warrant a separate context window, then an agent-as-tool integration likely justifies the complexity. On the other hand, if a client only needs a few tools but you only expose an agent, the integration complexity might not be worth the effort at all. Give flexibility to your clients by letting them choose their level of integration.