How Tools Work with AI Models: The Schema Layer That Makes Agents Useful

The Schema Is the Interface

When an AI model "uses a tool," it doesn't execute code. It doesn't import a library. It doesn't call a function. What it does is read a structured description of what a tool can do, decide whether that tool is relevant to the current task, and generate a JSON object containing the arguments it wants to pass. Your application then executes the actual function and returns the result.

This is the general architecture of tool use across major AI providers in 2026 — OpenAI, Anthropic, Google, and the open-source ecosystem. In the tool-calling interface, the model sees the schema rather than executing or inspecting the implementation. That schema is the entire interface contract.

Understanding this distinction is critical for anyone building with AI agents. The quality of your tool definitions directly determines whether the model calls the right tool, passes the right arguments, and produces useful results. Bad schemas produce bad tool calls — not because the model is incapable, but because you gave it the wrong map.

Anatomy of a Tool Definition

Every tool definition, regardless of provider, has three components:

Name — a short identifier the model uses to reference the tool. This appears in the model's output when it decides to call a tool. Names should be descriptive and unambiguous: get_weather is clear; process_data is not.

Description — a plain-English explanation of what the tool does and when to use it. This is the most important field. The model reads this description to decide whether the tool is relevant to the user's request. A vague description leads to incorrect tool selection. A precise description leads to correct tool selection.

Parameters — a JSON Schema object describing the inputs the tool accepts. Each parameter has a type, a description, and an indication of whether it's required. The model reads these definitions to decide what arguments to generate. Parameter descriptions should include the expected format, valid ranges, and concrete examples.

Here's what this looks like in practice. When you define a tool for Claude, you provide an input_schema with a top-level type of object, a properties map describing each parameter, and a required array listing mandatory fields. OpenAI uses the same structure under a parameters key. Google's Gemini follows the same pattern. The JSON Schema format has become the universal language for describing tools to AI models.

Why Descriptions Matter More Than Code

Tool calling reliability lives almost entirely in three places: the JSON Schema you give the model, the plain-English description attached to each tool and each parameter, and the error-handling logic in your agent loop. Of these three, the description is the highest-leverage surface.

Research and production experience in 2026 have established that vague descriptions are the primary driver of tool selection errors. When an agent has access to 30 tools and needs to pick the right one, it's reading descriptions — not executing code — to make that decision. A description that says "processes data" gives the model almost nothing to work with. A description that says "fetches the current weather forecast for a given city, returning temperature in Celsius and conditions" tells the model exactly when this tool is useful and what it returns.

This has given rise to what practitioners call tool description engineering — writing tool descriptions with the same care and precision as system prompts. [1] The description is part of the prompt. It occupies tokens in the context window. It influences the model's attention. It shapes the model's decision about what to do and how to do it.

Best practices have converged on keeping parameter descriptions under 20 words, including concrete examples of valid inputs, specifying return value format in the tool description, and using enum types to constrain parameter values wherever possible. [2]

The Token Cost of Tools

Tool definitions are not free. Every tool you expose to a model occupies tokens in its context window. Research shows that 31 tool definitions add approximately 4,500 tokens per query. [3] That's context space that could otherwise hold conversation history, retrieved documents, or reasoning.

This creates a tension: more tools give the agent more capabilities, but each additional tool dilutes the context available for everything else. Even with 2026's flagship models offering one million token windows, the practical impact is real. Studies have shown that surrounding text — including tool definitions — can degrade a model's ability to apply retrieved evidence effectively. The distinction between context capacity (how much a model accepts) and context fidelity (how well it uses what it accepts) matters here.

The implication: don't expose every tool you have. Expose the tools relevant to the current task. This is why tool routing and dynamic tool selection have become active areas of research.

How MCP Standardizes Tool Exposure

The Model Context Protocol addresses tool exposure at the infrastructure level. Instead of hardcoding tool definitions into your application, MCP servers expose tools through a standardized discovery protocol. An MCP client connects to a server, queries its available tools, and receives structured definitions — names, descriptions, and JSON Schema parameters — that it can inject into the model's context.

This architecture separates tool implementation from tool exposure. A PostgreSQL MCP server knows how to query databases. A Playwright MCP server knows how to automate browsers. Each server exposes its capabilities as tool definitions that any MCP-compatible AI client can discover and use. The model sees the same structured schemas regardless of whether the tool came from a local MCP server, a remote service, or a community-built integration.

For a deeper look at the protocol itself, see our article on Understanding MCP: The Protocol Connecting AI to Everything.

Tool Primitives in MCP

MCP defines tools as model-controlled primitives — the AI agent decides when and how to call them, based on the schema and description provided by the server. This is distinct from resources (data the model can read) and prompts (reusable templates that guide behavior). The tool schema follows the same JSON Schema format used by direct API integrations, making MCP a transport and discovery layer rather than a new definition format.

From Static Lists to Active Discovery

The traditional approach — injecting all available tool definitions into every prompt — is a static model that doesn't scale. As tool ecosystems grow into the hundreds or thousands, the token cost becomes prohibitive and the model's selection accuracy degrades.

Research published in 2025-2026 is addressing this head-on. MCP-Zero, an active tool discovery framework, enables models to dynamically identify capability gaps and request specific tools on demand. Instead of receiving a list of 2,797 tools from the official MCP repository at the start of a conversation, the model identifies what it needs, generates a structured request describing the required capability, and a semantic routing system matches that request to the right tool from the right server.

The results are striking: 60-98% reduction in token consumption compared to static tool injection, with maintained or improved task completion rates. [4] The approach uses hierarchical semantic routing — first matching to the relevant server, then to the specific tool — which scales logarithmically rather than linearly with the number of available tools.

Similarly, Dynamic ReAct extends the reasoning-and-acting paradigm to handle large-scale MCP environments where static tool lists would overwhelm the context window. These approaches signal a shift from "give the model everything" to "let the model ask for what it needs."

Strict Mode and Structured Outputs

A persistent challenge with tool use is schema compliance — ensuring the model's generated arguments actually match the schema you defined. In early implementations, models would occasionally generate malformed JSON, include extra fields, or use wrong types. This was a reliability problem that required defensive parsing on every tool call.

OpenAI's strict mode, introduced with Structured Outputs, addresses this by constraining the model at decode time. When strict: true is set in a function definition, the model's output is guaranteed to match the provided JSON Schema — not merely likely to, but guaranteed. This eliminated an entire category of runtime errors and moved schema compliance from roughly 80% in JSON mode to 100% in strict mode. [5]

Anthropic's approach with Claude achieves similar reliability through the input_schema definition, where the model uses the schema together with the description to decide how to fill in arguments. [6] The key insight across providers: the tighter and more precise your schema, the more reliable the tool calls.

Writing Tool Definitions That Work

The practical takeaways from two years of production tool use are clear:

1. Name tools for clarity, not brevity. search_knowledge_base beats search. The name is the model's first signal about what the tool does.
2. Write descriptions like documentation. Include what the tool does, when to use it, and what it returns. The model reads this to decide whether to call the tool — make the decision easy.
3. Describe every parameter. Type alone isn't enough. Include format expectations, valid ranges, and a concrete example. Keep descriptions under 20 words — tokenizers can misweight longer descriptions.
4. Use enum and required aggressively. Constrain the model's choices wherever possible. An enum with three valid values eliminates an entire class of invalid arguments.
5. Set additionalProperties: false. Prevent the model from inventing fields that don't exist in your schema. This is mandatory for strict mode and good practice everywhere.
6. Limit exposed tools to what's needed. Don't expose 50 tools when the task requires 5. Each unnecessary tool definition costs tokens and increases the chance of misselection.

Where This Is Heading

The trajectory is toward smarter, more dynamic tool exposure. Static tool lists are giving way to active discovery frameworks. Schema definitions are getting stricter, with decode-time enforcement becoming the norm. Tool description engineering is being recognized as a distinct skill — as important as prompt engineering was two years ago.

The models are getting better at tool use, but the interface contract remains the same: a name, a description, and a schema. The developers who write precise, well-constrained tool definitions will get reliable tool calls. The ones who don't will debug mysterious failures that have nothing to do with the model's capabilities and everything to do with the map they gave it.