MCP, in Plain Terms: How an Agent Actually Calls Your Tools
You've heard the term and want to know what it means for your project, not a protocol spec. Here's the short version, what we evaluate before using it, and what it changes about how safely an agent can act.
What Tool Use Actually Means
An agent that can only talk is a chatbot. An agent that can call tools can look something up in a live system, run a calculation, or trigger an action — and that's the difference this whole business is built on.
1. The agent decides it needs to act
Based on the conversation or the state it's reading, it identifies that a specific tool — a CRM lookup, a calendar check, a document search — is the right next step.
2. It makes a structured request
Not free text — a precise, structured call naming the tool and the exact inputs it needs, so the system on the other end knows exactly what's being asked.
3. The tool runs and returns a result
The actual system does the actual work — the agent doesn't fake the lookup or the update, it triggers the real one and waits for the real answer.
4. The agent uses the result to continue or escalate
It folds the result back into the task — answers, takes the next action, or decides the situation is outside what it should handle alone.
What the Protocol Actually Standardises
Before MCP, wiring a model up to call a tool usually meant writing custom glue code per tool, per project. MCP is an attempt to standardise that description and discovery step, so a tool built to the standard can be connected without reinventing that glue every time.
Worth It Where a Mature One Exists
If a well-maintained connector already covers a system you use, adopting it can save real build time and gives you an integration that isn't uniquely ours to maintain.
Often the Safer Default Today
For a system with no solid connector yet, or a workflow with unusual requirements, a direct integration against that system's own API is frequently more reliable than forcing it through an immature standard.
We evaluate this per system, per project — not as a blanket policy in either direction. What matters to you is that the agent can safely and reliably reach the tool, not which standard's name is on the wiring.
What Decides Whether to Use It on Your Project
Connector Maturity
Whether a solid, maintained connector exists for the systems you actually use, or whether we'd be building and maintaining one from scratch either way.
Permission Model
How granularly access can be scoped — whether the agent can be limited to exactly the actions the job needs, not broad standing access.
Failure Behaviour
What happens when a tool call fails or returns something unexpected — it should fail safely and visibly, not silently guess and carry on.
Tool Access Is Scoped, Not Open-Ended
A tool-using agent is only as safe as what it's allowed to call. We define the exact list of tools an agent can reach, the exact inputs each one accepts, and which calls need a human confirmation before they run — the same escalation discipline behind every agent we build, applied at the level of individual tool calls.
See How Integrations Are Scoped
Questions About MCP & Tool Use
Is MCP a specific product we need to buy?
No. It's an open protocol — a standardised way for a model to discover and call external tools — not a product with a licence fee. Several tools built around it are open source. Whether we use it on your project depends on whether a mature connector already exists for your systems.
Do we need MCP specifically, or just an agent that can take action?
Usually the second. MCP is one way of wiring tool access, and a genuinely useful one where a solid connector already exists for your systems. Where it doesn't, a direct custom integration is often more reliable, and we'll say so rather than force-fitting a standard because it's the current term.
How do you stop an agent from calling the wrong tool, or calling one it shouldn't?
Each tool the agent can call is scoped in advance — what it can be used for, with what data, and under what conditions. Higher-stakes tool calls can be gated behind a human confirmation step, the same escalation principle that runs through every agent we build.
Is this the same as function calling?
Closely related. Function calling is the underlying mechanism — a model producing a structured request to run a specific function. MCP standardises how those functions get described and discovered across different tools and systems, rather than each integration inventing its own format.
Will this still be the right choice in a year?
We won't pretend to know that with certainty — tool-calling standards are genuinely still moving. What we commit to is evaluating the current landscape honestly at build time and building the integration layer so it can be swapped out later without rebuilding the whole agent.
Tell Us What You Want the Agent to Reach
We'll tell you plainly whether MCP, a direct integration, or something simpler is the right call for your systems.