A language model on its own is a very good text transformer with no access to your data and no ability to change anything. Every genuinely useful enterprise application of LLMs involves closing that gap: letting the model read from your systems and, carefully, write back to them. Tool calling is the mechanism, and the Model Context Protocol (MCP) is an increasingly common way to standardize how those tools are exposed.
This article covers how tool calling actually works, what MCP adds on top of it, and — more usefully — how to design the tool layer so it does not become the most fragile part of your architecture.
How Tool Calling Actually Works
The mechanics are simpler than the marketing suggests. You send the model a list of available tools, each with a name, a description, and a JSON Schema describing its parameters. The model, instead of replying with prose, may reply with a structured request to call one of those tools with specific arguments. Your code executes that call, returns the result, and the model continues with the result in context.
Three things follow from this that people consistently get wrong.
The model does not execute anything. It emits a request. Your application decides whether to honor it. Every authorization, validation, and rate-limiting decision happens in your code, and none of it can be delegated to the model. This is a feature: it means the entire security surface is under your control if you choose to use it.
Tool descriptions are prompt engineering. The description field is not documentation for humans. It is the only thing the model uses to decide when a tool applies. A vague description produces a tool the model calls at the wrong times or ignores entirely. Descriptions should state what the tool does, when to use it, when not to use it, and what the result looks like.
Schemas are the contract, and the model will test it. Enums, required fields, format constraints, and value ranges in your schema constrain what the model can produce. Anything you leave loose, you will eventually receive. A string parameter for a date will get you every date format that exists.
Parallel and Sequential Calls
Models can request several tool calls at once when the calls are independent, and most modern APIs support returning all the results together. This matters for latency: fetching a customer record, their open tickets, and their subscription status in parallel is one round trip instead of three.
Sequential dependencies — where the second call needs the first call’s output — cost a full model round trip each. If you find a common sequence repeating, that is a signal to collapse it into a single composite tool rather than letting the model orchestrate it every time.
What the Model Context Protocol Adds
Tool calling is a model API feature. Every integration you build with it is bespoke: your code, your process, your deployment. MCP is an open protocol that standardizes the interface between an AI application and a tool provider, so a tool implementation can be reused across different clients rather than rewritten for each one.
An MCP server exposes three main kinds of capability:
- Tools — functions the model can invoke, the same concept as native tool calling but discovered over the protocol rather than hardcoded in the client.
- Resources — data the client can read and place into context, such as files, records, or documents. Resources are application-controlled rather than model-invoked, which makes them a natural fit for things you want deterministically included.
- Prompts — reusable, parameterized prompt templates that a server can offer, typically surfaced as user-selectable commands.
Servers can run as a local subprocess communicating over stdio, or as a remote service over HTTP. The local pattern suits developer tooling and anything touching a workstation; the remote pattern suits shared enterprise systems where you want one governed integration rather than one per laptop.
Why This Matters Architecturally
The practical value of MCP is decoupling. Without it, every AI client that needs access to your ticketing system implements that access itself, with its own auth handling, its own error semantics, and its own bugs. With it, one server implementation serves any compliant client — an internal assistant, a coding tool, an automation runner.
This maps neatly onto how enterprises already think about integration. An MCP server is, functionally, an API gateway for model consumers: a governed boundary where you centralize authentication, authorization, audit logging, rate limiting, and schema versioning. Teams that already run a disciplined API and integration layer will find the pattern familiar, and should probably build MCP servers as a thin, well-governed facade over existing services rather than as a new parallel access path.
Where MCP Is Not the Answer
MCP adds a protocol layer and a process boundary. If you are building a single application with a fixed set of five internal tools that no other client will ever use, native tool calling in your own code is simpler, faster, and has fewer moving parts. Adopt MCP when reuse across clients, third-party tool ecosystems, or a clean governance boundary are genuinely worth the indirection.
Designing the Tool Layer
Whether tools are exposed natively or over MCP, the design principles are the same — and they determine whether the system is reliable.
Model Tools on Intent, Not on Endpoints
The instinct is to wrap each existing REST endpoint as a tool. This produces a large, undifferentiated tool list where the model must compose several low-level calls to accomplish anything, and every composition is a chance to get it wrong.
Better to expose tools that correspond to complete user intents: find_customer_by_email, summarize_account_health, create_support_ticket. Each is a single call with a clear success condition. The multi-step orchestration lives in your code, where it is testable and deterministic, rather than in the model’s reasoning, where it is neither.
Keep the Tool List Small
Model accuracy in tool selection degrades as the number of available tools grows, particularly when descriptions overlap. Twenty well-differentiated tools generally work better than eighty granular ones.
When you genuinely need a large surface, the fix is dynamic tool exposure: route the request to a subset of tools based on the task, using a cheap classifier or explicit user context. The model only ever sees the tools relevant to what it is currently doing.
Make Results Model-Legible
Tool results go into the context window and are read by a language model, not parsed by a program. This has implications:
- Trim aggressively. Returning a full API response with forty fields when three are relevant wastes context and buries the signal. Project down to what matters.
- Paginate with explicit affordances. Do not return 500 rows. Return the first 20 plus a clear indication that more exist and how to request them.
- Write errors as instructions.
403 Forbiddenis a dead end. “This account is not accessible with the current user’s permissions. Ask the user to request access or choose a different account.” lets the model recover or explain. - Include units and identifiers.
{"amount": 1500}is ambiguous.{"amount": 1500, "currency": "USD", "period": "monthly"}is not.
Enforce Authorization at the Tool, Every Time
The model should never be the thing deciding whether an action is permitted. Every tool invocation must independently verify the caller’s identity and permissions, using the end user’s scoped credentials where the tool acts on their behalf.
This matters more with tool calling than with ordinary APIs because of prompt injection. Content the model reads — a document, an email, a web page, a support ticket — can contain instructions attempting to redirect its behavior. There is no reliable way to make a model immune to this. The mitigation is that a successful injection can only cause actions the authenticated caller was already allowed to take, and that anything destructive requires confirmation outside the model loop.
Version Tools Like Public APIs
Changing a tool’s schema changes model behavior in ways your tests may not catch, because the model’s interpretation of a parameter shifts with its description. Treat tool definitions as a versioned public interface: additive changes are safe, renames and semantic changes are breaking, and both deserve a regression run against a saved set of representative tasks before rollout.
Practical Integration Patterns
Read-Only First
The lowest-risk useful deployment is retrieval and reporting: let the model read across systems that a person would otherwise have to check manually. This delivers value, builds a body of real usage logs, and exposes the tool-description and result-formatting problems before any write path exists.
Propose, Then Confirm
For write operations, split the action into a proposal the model generates and a confirmation step outside the model. The confirmation can be a human click, a rules engine, or a policy check — the point is that the irreversible step is never a direct consequence of a single model output.
Deterministic Rails Around Non-Deterministic Steps
Many workflows are mostly mechanical with one genuinely judgment-heavy step. Structure them that way: ordinary code handles routing, validation, and persistence; the model handles the interpretation step; tool calls connect them. This is the same division of labor that makes RPA and intelligent automation effective — rules where rules work, models where they do not.
If you are building agent loops on top of this layer, the surrounding controls matter as much as the tools themselves; our writeup on shipping AI agents to production covers the budget, evaluation, and monitoring side. And if you are wiring models into developer workflows specifically, the current landscape of AI coding tools is largely a story about which ones have the best tool integration.
Observability
Log every tool call: which tool, what arguments, what result, how long it took, which model version requested it, and which user identity it ran under. This log is simultaneously your audit trail, your debugging surface, and your evaluation dataset.
The metrics worth alerting on are tool error rates by tool, argument validation failure rates (a rising rate usually means a description or schema is misleading the model), and the distribution of calls across tools (a tool that is never selected is either unnecessary or badly described).
Conclusion
Tool calling is the mechanism that turns a language model from a text generator into something that participates in your systems, and MCP is a reasonable standard for exposing those tools once more than one client needs them. But the protocol is the easy part. The engineering that determines whether the result is reliable lives in the tool layer: intent-shaped tools rather than endpoint wrappers, tight schemas, small well-differentiated tool sets, model-legible results, authorization enforced in code, and versioning discipline.
Get that layer right and the model becomes a genuinely capable interface to your systems. Get it wrong and you have built a very expensive way to call the wrong API with the wrong arguments.
