AI Agent Tooling Standards: MCP, Function Calling, and What “Tool Use” Actually Requires

An AI agent is only as useful as the tools it can use and only as safe as the constraints around them. The standards for that have matured quickly, and it is worth being precise about what they cover, and what they leave to you.

Two standards with practical weight

Function calling. The model is given typed tool schemas and, when it decides a tool is needed, returns a structured request, function name, arguments, rather than prose. Every major provider supports it. It is what makes an agent's intent machine-readable, and it is the floor.

The Model Context Protocol (MCP). An open standard for how tools, data sources and prompts are exposed to agents through a common interface. A tool built as an MCP server can be used by agents on different models and platforms without being rewritten. Its value is decoupling: the tool's implementation, schema and permissions live in one place. For a company building several agents against the same systems, that is the difference between one integration and five.

They are complementary. Function calling is how the model asks; MCP is where the tools live and how any agent reaches them.

What neither standard gives you

The standards define the interface. Production requires five things the interface does not enforce.

Scoped permissions. A tool that reads the CRM and a tool that deletes from it are different tools with different credentials. Never give an agent a general-purpose API key.

Idempotency. Agents retry. A "create order" call that runs twice must not create two orders. Design every mutating tool so a repeated call with the same inputs is safe.

Structured errors. A tool that fails should return something the agent can reason about, what failed, whether retrying makes sense, not a stack trace or a silent null.

A human boundary. Anything that moves money, changes a customer's position, sends an external communication or deletes data sits behind an approval step at a defined confidence threshold. The standards will happily let an agent call a refund tool; your design decides whether it may.

Logging. Every tool call, with arguments and result, per run. When the agent does something surprising, this is how you find out why. It is also what an audit asks for.

A pattern that holds up

Expose systems through MCP servers with narrow, typed tools. Register only the tools an agent's job requires. Route mutating tools through an approval layer. Log everything. Evaluate against real cases before launch, and again whenever a model version changes. Our enterprise knowledge base methodology covers the retrieval side of the same architecture, and our agentic AI governance framework sets out the boundaries at enterprise scale.

A worked example: one agent, four tools

Take a support agent for an online retailer. It needs to read an order, check a return policy, create a return authorisation and, in a small number of cases, issue a refund. Four tools, four different risk levels. Reading an order is safe and gets a read-only credential scoped to the customer in the conversation. The policy lookup is retrieval over approved documents. Creating a return authorisation changes state, so it is idempotent: calling it twice with the same order returns the same authorisation rather than creating a second one. The refund tool never runs on its own. It drafts the refund, attaches the reasoning and the order history, and routes it to a person who approves with one click. Each tool is exposed through an MCP server, which means when the retailer later builds a second agent for the warehouse team, those same tools are already there, with the same permissions and the same logging. That reuse is the practical argument for the protocol.

Errors the agent can reason about

Most tool integrations return errors written for developers: a stack trace, an HTTP 500, a null. An agent cannot do anything useful with those. The pattern that works is to return structured failures that describe what happened and whether retrying makes sense. Order not found is different from order service unavailable, and the agent should tell the customer different things. Rate limited means wait and try again; permission denied means stop and escalate. We define an error schema per tool, alongside the input and output schemas, and we test the agent against every error case before launch. This sounds tedious. It is also where a surprising share of production incidents come from, because an agent that receives an error it does not understand will often try something creative, and creative is the last thing you want from software holding a refund tool.

Testing before launch

An agent with tools needs three kinds of test, and most projects run only the first. The first is the happy path: real cases from your history, run end to end, scored. The second is the adversarial set: a customer asking for a refund on an order that is not theirs, a request phrased to make the agent skip the approval step, an input that looks like an instruction to the agent rather than a question. The agent must decline every one. The third is the failure set: each tool made to fail in each of its defined ways, with the agent expected to recover or escalate cleanly. We keep all three in version control next to the tool definitions, and we re-run them whenever a tool changes, a prompt changes, or the model provider announces a version. It takes an afternoon to set up and it is the difference between an agent you can trust with a real system and one you cannot.

Where the standards are heading

Two things are changing fast enough to matter for a system you build this year. The first is that MCP is becoming the default way tools are published, which means more of the systems you already use will expose an MCP server rather than an API written just for one integration. That reduces integration work, but it also means the permission model you design has to handle tools you did not write. Treat a third-party MCP server the way you would treat a third-party library: read what it can do, give it the narrowest credential that works, and log its calls like any other. The second change is that the model providers are moving more of the orchestration into their own platforms, with built-in tool loops and memory. That is convenient, and it is also a form of lock-in. We keep the tool definitions, the permission layer and the evaluation set outside any single provider's platform, so that switching models is a configuration change rather than a rebuild. It has already saved two clients a rewrite.

What to write down before the first tool is built

One page, before anyone opens an editor. For each tool the agent will use: what it reads, what it changes, which credential it uses and how narrow that credential is, whether calling it twice is safe, what its failures look like, and whether a person has to approve it. Add the confidence threshold at which the agent stops and asks, and what the person receives when it does. That page becomes the test plan, the security review answer and the onboarding document for the next engineer, and it takes an hour. We have watched teams skip it to save that hour and then spend a week in month two working out why the agent occasionally created duplicate orders. The standards give you a way to publish tools. The page is how you decide what the tools are allowed to do.

What we build

Our AI agent development work follows this pattern by default, MCP-exposed tools, scoped credentials, idempotent mutations, an approval boundary and per-run tracing, because the alternative is an agent nobody can trust with a real system. The LLM integration layer underneath handles the model routing, and our comparison of OpenAI vs Claude covers how the leading models differ in tool-use reliability.