Why Tool Calling Without a Standard Protocol Doesn't Scale in Agent Systems

Three agents, twelve tools, two model providers. Your first demo ships in a week. Six months later you have seven agent surfaces — Slack bot, IDE plugin, internal web app, customer-facing copilot, cron-driven batch agent, vendor sandbox, mobile prototype — and forty-one integrations maintained by four teams who do not share code. Every new SaaS connector gets rewritten from scratch. That is not a tooling problem. It is an economics problem that a standard protocol is meant to address.

The N×M integration tax#

Without a shared protocol, each host (the application running the model loop) implements its own:

• Tool schema format and validation
• Auth handoff and token storage
• Discovery mechanism (usually: hardcoded list in repo)
• Error translation for the model
• Logging and replay format for evals

Each capability (Jira, GitHub, internal CRM) gets adapted per host. The math is brutal:

Even at 50% reuse through internal libraries, you are still paying coordination cost: versioning, breaking changes, and "which adapter is canonical?" meetings. A protocol does not reduce C. It collapses the adapter surface toward C servers + H thin hosts instead of H×C forks.

Why internal SDKs stop scaling#

Mature teams build @corp/agent-tools and declare victory. It works until:

• A vendor host (Cursor, Claude Desktop, a partner's agent runtime) cannot import your private npm package
• Python agents fall behind because the SDK is TypeScript-first
• Tool schemas embed host-specific assumptions (your web app's session model, not theirs)
• Security review wants per-host allowlists the SDK was never designed to express

Internal SDKs solve code reuse inside your repo. They do not solve cross-host interoperability — which is exactly where agent systems are heading as models spread across IDEs, ops consoles, and customer channels.

Compounding maintenance you do not forecast#

The hidden line items in a bespoke stack:

Schema drift. Backend team renames assignee_id to owner_id. Your Slack bot adapter updates on Tuesday. The IDE plugin still sends the old field until someone notices in prod evals.

Prompt-documented tools. Tool descriptions live in system prompts copied across repos. Updating "how to call search" means a PR in five places and a missed one causes tool-selection regression.

Auth duplication. Each host stores OAuth refresh tokens differently. Rotating a client secret becomes a multi-app fire drill.

Eval fragmentation. Replay logs from one host do not match another's format. You cannot compare tool-success rates platform-wide.

Onboarding tax. Every new engineer learns your custom tool abstraction before they learn the business domain.

A standard protocol does not erase these costs. It names the seams: discovery, call, resource fetch — so platforms invest once in host infrastructure.

Engineering economics of protocol adoption#

Treat protocol adoption as a build-vs-buy on interface stability:

# Bespoke: every host reimplements discovery + call semantics
class LegacyToolRegistry:
    def __init__(self):
        self._tools: dict[str, ToolSpec] = {}

    def register(self, name: str, fn: callable, schema: dict):
        self._tools[name] = ToolSpec(name=name, fn=fn, schema=schema)

    def for_model(self) -> list[dict]:
        return [{"name": t.name, "parameters": t.schema} for t in self._tools.values()]

# Protocol-aligned: host delegates catalog to MCP session
async def tools_for_model(session: McpSession, allowlist: set[str]) -> list[dict]:
    discovered = await session.list_tools()
    return [
        {"name": t.name, "description": t.description, "parameters": t.inputSchema}
        for t in discovered
        if t.name in allowlist
    ]

The second path front-loads work: MCP client in the host, server implementations for capabilities, catalog governance. The return appears when host #3 ships in days instead of quarters because it inherits discovery, call routing, and schema parsing.

Break-even usually lands between two and four hosts sharing ten or more capabilities — earlier if external vendor hosts must connect without your SDK.

What "scale" means here (and what it does not)#

Scaling agent tool integrations is not about QPS through a gateway. It is about:

• Organizational scale — more teams shipping agents without a platform bottleneck
• Surface scale — more places the same capability must appear with consistent policy
• Vendor scale — third-party hosts and servers entering your ecosystem
• Lifecycle scale — schema versions, deprecations, and security patches propagated predictably

A single-team agent with five cron jobs does not need MCP tomorrow. An enterprise building an agent platform for dozens of internal products does — not for hype, but to avoid becoming the permanent adapter factory.

Adoption path that respects the math#

1. Inventory hosts and overlapping capabilities. If only one host needs a tool, defer MCP wrapping.
2. Extract the first shared server where two hosts already duplicate code — tickets read-only is a common win.
3. Invest in host-side policy once — allowlists, audit logging, schema validation before model exposure.
4. Publish a catalog with owners, SLAs, and semver for tool schemas.
5. Migrate hosts incrementally — bespoke registry and MCP discovery can coexist during transition.
6. Measure adapter count over time. The metric should fall or flatten as servers grow.

Summary#

Tool calling without a standard protocol scales poorly because every new host multiplies integration work against every capability. Internal SDKs help until cross-language, cross-vendor, and cross-team boundaries appear. MCP trades upfront platform investment for a stable discovery-and-call contract that servers implement once and hosts consume thinly.