Why the Industry Can't Agree on What a "Tool" Is (And What It Costs You)

Table of Contents

• What a Tool Definition Actually Is
• The State of Standardization Right Now
• Why JSON Schema Didn't Solve It
• The Hidden Costs for a GaaS Operator
• Where MCP Fits and Where It Stops
• How to Build a Provider-Neutral Tool Layer
• Governance: Who Actually Controls the Standard
• Insights Most People Overlook
• Frequently Asked Questions
• Conclusion
• References

What a Tool Definition Actually Is

Strip away the marketing and a tool definition is a contract. It tells a language model three things: the tool's name, what it does, and the shape of the arguments it accepts. Most of the industry expresses that contract as a JSON Schema object wrapped in some provider-specific envelope. A send_email tool, for instance, declares a to string, a subject string, a body string, and maybe a boolean for html.

That sounds trivial. It isn't, and the reason is that the definition does double duty. It's a machine contract the runtime uses to validate and dispatch the call, and it's a prompt, the description field is read by the model to decide whether and how to invoke the tool. A schema that's technically valid but vaguely described produces an agent that calls the wrong tool at the wrong time. So the "standard" we're chasing isn't just a data format. It's a format plus a set of conventions about how you write descriptions, how you signal required versus optional fields, how you handle enums, and how you communicate that a parameter is dangerous or irreversible.

This dual nature is exactly why the problem resists a clean fix. You can standardize bytes on a wire. Standardizing how thirty different platforms coach a model to behave is a different and much messier project, and it's the one that actually determines whether your agents work.

The State of Standardization Right Now

Here's the honest map as of mid-2026. There is no single industry standard. There are several overlapping conventions, and they cluster into three layers.

At the model-provider layer, each major lab ships its own tool-calling format. OpenAI popularized the functions/tools array with a parameters object that is JSON Schema. Anthropic's tool use documentation uses an input_schema field that is also JSON Schema but lives in a differently shaped request. Google's Gemini function declarations use yet another envelope. The inner schema is broadly compatible; the outer envelope is not. Translating between them is mechanical but lossy, because each provider supports a slightly different subset of JSON Schema features and a different ceiling on how many tools you can attach before quality degrades.

At the protocol layer, the Model Context Protocol (MCP) introduced by Anthropic in late 2024 is the closest thing to a cross-vendor standard the industry has. MCP defines how a server exposes tools (and resources and prompts) to any client over a defined transport, so a tool written once can be consumed by Claude, by OpenAI's stack, and by a growing list of others. It's been adopted far faster than most expected. But MCP standardizes transport and discovery, how an agent finds and lists tools, more than it standardizes the semantics of the tool definition itself, a distinction explored in the MCP standard explained for operators.

At the framework layer, LangChain, LlamaIndex, and the rest each maintain their own tool abstraction, then compile down to whatever the underlying provider wants. This is genuinely useful and genuinely part of the problem: every framework becomes its own micro-standard with its own decorators, its own type coercion, and its own quirks.

So when someone says "we should standardize tool definitions," ask them which layer they mean. The answer is usually "all of them," and that's why it hasn't happened.

Why JSON Schema Didn't Solve It

JSON Schema looks like the obvious common denominator. Everyone already uses it. So why isn't it enough?

Three reasons, and they compound.

First, JSON Schema is a big spec with optional corners, and providers implement different corners. oneOf, allOf, recursive $ref, additionalProperties, format validators, conditional if/then, support for these varies. A schema that validates perfectly against one model's tool-calling endpoint gets silently rejected or flattened by another. You discover the incompatibility in production, not in the linter.

Second, JSON Schema describes structure, not behavior. It can say a field is a string matching a date pattern. It cannot say "this tool charges the customer's card and cannot be undone." That semantic metadata, idempotency, side effects, cost, required confirmation, is exactly what an agent needs to behave safely, and it's exactly what the schema standard doesn't carry. Each platform bolts it on with custom extensions, which fragments things further.

Third, the model reads the schema as a prompt, and prompt sensitivity is provider-specific. The description style that makes Claude reliably pick the right tool isn't identical to what Gemini wants. A truly portable definition would have to be prompt-neutral, but tool-calling reliability is downstream of prompt phrasing, a tension covered in depth in tool-calling reliability at the infrastructure layer. You can normalize the JSON; you can't fully normalize the persuasion.

This is why "just use JSON Schema" is true and insufficient at the same time. The schema is the easy 60%. The remaining 40%, the behavioral metadata and the prompt-tuning, is where portability actually breaks.

The Hidden Costs for a GaaS Operator

If you sell agents as a service, fragmentation isn't an abstract standards-body debate. It shows up on your P&L and your incident channel.

Multiplied maintenance. Every tool you expose has to be defined, tested, and re-validated for each model you route to. If you run a multi-model routing layer to keep inference cheap, you're now maintaining N translations of every tool. Add a parameter to one tool and you touch N code paths. This is the kind of overhead that quietly eats the margin on per-task pricing.

Silent reliability drift. Because each provider flattens unsupported schema features differently, the same tool can behave subtly differently across models. A nested object that one model handles cleanly gets stringified by another, and your agent starts passing malformed JSON to a downstream API. These failures are intermittent and model-dependent, which makes them brutal to reproduce.

Lock-in by accident. Teams that hand-tune tool descriptions for one provider's quirks find they've effectively married that provider. Switching models means re-tuning every tool, which is precisely the vendor lock-in that a service business should be avoiding. Standardization, or at least a clean abstraction layer, is what buys you the freedom to route to whoever is cheapest and most reliable this quarter.

Security surface sprawl. Every translation layer is a place where a permission boundary can leak. If the "requires confirmation" flag exists in your internal definition but doesn't survive translation to a given provider's format, you've just shipped an agent that executes an irreversible action without a checkpoint. Tool definitions are a security artifact, not just a config artifact.

Where MCP Fits and Where It Stops

MCP deserves a clear-eyed assessment because it's both the most promising development and the most overhyped one.

What MCP genuinely fixes: it gives you one way to expose a tool server that many different clients can consume. Write an MCP server for your internal CRM once, and any MCP-aware agent can discover and call it. That collapses a real chunk of the integration matrix and is why adoption has been so fast, it solves a concrete pain rather than proposing an aspirational meta-standard. For an operator, an MCP server becomes a reusable asset across products, which is the kind of leverage that compounds.

What MCP does not fix: it doesn't make the underlying model tool-calling formats identical, and it doesn't standardize the behavioral semantics discussed above. An MCP server still describes its tools with JSON Schema, so the schema-feature-support problem rides along. MCP also pushes some hard questions outward rather than solving them, authentication, rate-limiting, and policy enforcement around tool calls still need an agent gateway sitting in front. And the discovery model raises its own governance questions: when an agent can auto-discover dozens of tools, you need curation, or you drown the model in options and watch reliability fall off a cliff.

The honest framing: MCP standardizes the plumbing between agents and tools better than anything before it, and it's worth building on. It does not yet standardize the definition semantics in a way that makes a tool behave identically across every model. Treat it as a strong foundation, not a finished house.

How to Build a Provider-Neutral Tool Layer

You can't wait for the industry to converge, you have agents to ship now. The practical move is to build an internal abstraction that insulates you from the churn. Here's the architecture that holds up.

Keep one canonical definition per tool. Define each tool exactly once in your own internal format, richer than any single provider's, because it carries the behavioral metadata they omit: idempotency, side-effect class, cost estimate, confirmation requirement, and a human-readable description that's deliberately written to be prompt-neutral. This canonical record is your source of truth. Everything else is generated from it.

Compile down at runtime, not by hand. Write adapters that translate the canonical definition into each provider's envelope on demand. When you add a provider, you write one adapter, not a re-definition of every tool. When you add a tool, the adapters pick it up automatically. This is the single highest-leverage decision in the whole stack, and it's closely tied to building reliable tool integrations for agents.

Validate against each target's schema subset. Don't assume a feature works because it's valid JSON Schema. Maintain a capability matrix of what each provider actually supports, and fail loudly at build time when a canonical tool uses a feature a target can't handle. Better a build error than a silent production flatten.

Make behavioral metadata enforceable, not decorative. If a tool is flagged irreversible, your runtime, not the model, should insert the human-in-the-loop checkpoint, regardless of which provider you routed to. Safety semantics must live in your layer, above the model, so they survive every translation. Never trust the provider format to carry them.

Version the definitions. Tools change. A parameter gets renamed, an enum gains a value. Treat tool definitions as versioned artifacts in your agent CI/CD pipeline so you can roll back a definition that tanks reliability without redeploying the whole agent.

Do this and provider fragmentation becomes a contained problem at the edge of your system instead of a tax spread across every feature.

Governance: Who Actually Controls the Standard

It's worth being clear-eyed about the politics, because standards are never purely technical.

The labs have an incentive to make their format good enough to be sticky but not so open that switching is frictionless. MCP being open and Anthropic-originated is a genuinely positive signal, but adoption by a competitor doesn't guarantee identical implementation, partial or "extended" adoption is the classic way a nominal standard fragments in practice. We've watched this movie with browsers and with SQL.

The likeliest path isn't a formal standards body blessing one definition format. It's de facto consolidation: MCP becomes the dominant transport and discovery layer, JSON Schema remains the dominant inner format, and a thin set of conventions for behavioral metadata emerges from whoever ships the most-used agent runtime, a dynamic protocol fragmentation and the coming consolidation examines in detail. Industry analysts tracking the agent infrastructure space, including coverage from firms like Gartner on AI agent platforms, expect the orchestration and protocol layers to consolidate well before the semantic-metadata layer does.

For an operator, the strategic takeaway is not to bet the company on any one format winning. Bet on your own abstraction layer, adopt MCP where it earns its keep, and stay liquid enough to move when the consolidation finally lands.

Insights Most People Overlook

The description field is more load-bearing than the schema. Teams obsess over getting the JSON structure portable and underinvest in the natural-language description. In practice, two schemas that are byte-identical but differently described produce wildly different agent reliability. The hardest part of standardization isn't the structure everyone argues about, it's the prose nobody treats as a standard at all.

Fewer tools beats standardized tools. A perfectly portable tool definition still hurts you if you attach forty of them to one agent. Every major model degrades as the tool count climbs. The real reliability win often isn't standardizing more tools, it's exposing fewer, sharper ones per agent, and using a supervisor pattern to route. Standardization is necessary; restraint is what actually moves the metric.

Behavioral metadata is the unclaimed standard. Everyone's fighting over schema format, which is mostly solved. Almost no one is standardizing idempotency, cost, and side-effect declarations, the metadata that makes agents safe. Whoever defines that convention well will shape agent security for a decade, and it's currently a gap, not a battleground. There's a first-mover advantage sitting unclaimed.

MCP's discovery feature is a double-edged sword. The ability to auto-discover tools is celebrated as a feature. For a production GaaS operator it's also a liability: uncurated discovery means an agent can find a tool you never vetted, with a description you didn't write. Mature operators will disable open discovery and curate an explicit allowlist, the opposite of the demo-friendly default.

Translation layers are where audits fail. When a compliance auditor asks "can this agent move money without a human approving it," the answer lives in whether your confirmation flag survives every provider translation. Most teams can't answer confidently because the flag exists in three formats and got dropped in one. The standardization gap is, quietly, an audit gap.

Frequently Asked Questions

Is MCP going to become the universal tool standard? It's the strongest candidate for the transport and discovery layer, and adoption has been fast. But "universal standard" overstates it, MCP standardizes how tools are exposed and found more than how their behavior is defined. Expect it to dominate one layer while JSON Schema and a patchwork of conventions cover the others.

Can I just convert OpenAI tool definitions to Anthropic's format with a script? For simple tools, yes, the inner schema is largely compatible. The risk is in the corners: unsupported schema features, tool-count limits, and the fact that descriptions tuned for one model may underperform on another. Automate the structural translation, but test reliability per provider rather than assuming parity.

Where should "this action is irreversible" live? In your own canonical definition and enforced by your runtime, never solely in a provider's format. Provider envelopes don't reliably carry side-effect semantics, so if your safety logic depends on the format preserving a flag, it will eventually fail. Keep enforcement above the model.

Does standardizing tool definitions improve agent reliability on its own? Indirectly. Consistent definitions reduce a class of integration bugs, but reliability is driven more by description quality, tool count, and validation than by format uniformity. Standardization removes failure modes; it doesn't manufacture reliability.

How does this relate to A2A and agent-to-agent protocols? Tool definitions describe how an agent calls a tool; agent-to-agent protocols describe how an agent calls another agent. They're adjacent standardization efforts, and the same fragmentation dynamics apply. An agent exposed as a tool to another agent inherits all the definition-semantics problems discussed here.

Should a small operator build a canonical tool layer, or is that overkill? If you run a single model and a handful of tools, a full abstraction layer is premature. The moment you route across two or more providers, or expose more than a dozen tools, the canonical-definition pattern pays for itself quickly. Build it when the maintenance multiplier starts to hurt, not before.

Conclusion

Standardizing tool definitions sounds like a tidy data-format problem and turns out to be three problems wearing a trench coat: a schema-compatibility problem that JSON Schema mostly but not fully solves, a behavioral-semantics problem almost nobody is standardizing, and a prompt-sensitivity problem that may never fully standardize because models differ in how they read descriptions. MCP is the most important step forward, it standardizes the plumbing and has spread fast, but it standardizes discovery and transport more than definition semantics, and it brings its own curation and governance questions.

For a GaaS operator, the winning posture isn't to wait for consensus. It's to own a canonical, behavior-rich tool definition internally, compile it down to each provider at runtime, enforce safety semantics in your own layer above the model, and adopt MCP where it earns its keep. That keeps you liquid as the inevitable consolidation plays out, protects your margins from the maintenance multiplier, and, most importantly, keeps the "this charges a customer's card" flag from silently disappearing in translation. The standard will eventually settle. Your architecture should make you indifferent to exactly when, and exactly whose, it is.

References

• Anthropic, Tool use (function calling) documentation
• Model Context Protocol, Official site and specification
• Gartner, Artificial Intelligence insights and agent platform research