Ask most vendors what their AI agent does and you’ll get a fluent answer: it answers questions, summarises documents, handles tickets. Push harder — “but how does it actually read our ERP?” — and the conversation gets vague fast.
That vagueness is worth paying attention to. The gap between an agent that talks about doing something and one that actually does it comes down to one thing: tool use. Specifically, how an agent is wired to reach your real systems — databases, CRMs, ERPs, calendars, document stores — and what standards govern that wiring.
This article explains how AI agents use tools, what the Model Context Protocol (MCP) actually is, and the concrete questions you should be asking any vendor before you commit.
The Difference Between a Chatbot and an Agent That Does Work
A language model on its own has no hands. It processes text and returns text. That’s useful for drafting and summarising, but it cannot check your inventory, update a customer record, or dispatch a purchase order without something extra.
That something extra is tool use — the mechanism by which an agent calls external functions, APIs, or services mid-conversation and incorporates the results into its reasoning. The agent receives a description of available tools (think: “get_order_status(order_id)”, “create_calendar_event(…)”), decides which tool to call and with what parameters, executes it, and uses the response to produce a useful output or take a next step.
This is also what separates an AI agent from a simple chatbot or copilot. A chatbot retrieves and rephrases. An agent with tools reads, decides, acts.
What Tool Use Actually Looks Like
Consider a logistics coordinator asking an agent: “Which open orders are at risk of missing this Friday’s cutoff?”
Without tools, the agent invents a plausible-sounding answer. With tools, the sequence looks like this:
- The agent calls
get_open_orders(status="pending", due_before="2026-06-13")against your ERP. - It receives a list of twelve orders with their current carrier statuses.
- It calls
get_estimated_delivery(order_id=...)for each one where the status is uncertain. - It compares estimated delivery dates against the cutoff and flags the three that are at risk.
- It returns a summary with order numbers, the gap in days, and the name of the responsible account manager from your CRM.
None of that is possible without the tools. The tools — and the agent’s ability to chain them across multiple calls — are what make the outcome operationally useful. This chaining of tool calls within a single task is the core of what agentic workflows really mean in practice.
Where MCP Fits: The Integration Layer Explained
Defining individual tools for every system an agent needs to reach is expensive engineering work. You write the function, handle authentication, manage API versioning, and repeat this for every data source. For a small number of integrations in a controlled environment, that’s manageable. For a company with a CRM, an ERP, a document store, a ticketing system, and a calendar — all from different vendors — it becomes a significant maintenance burden.
Model Context Protocol (MCP) is an open standard, published by Anthropic in late 2024, that tries to solve this. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund of the Linux Foundation co-founded by Anthropic, Block, and OpenAI — reinforcing its status as a genuinely vendor-neutral standard. The idea is straightforward: rather than baking integrations directly into the agent, MCP defines a common interface. A system that implements MCP exposes its data and actions as an “MCP server.” An agent runtime that supports MCP can connect to any compliant server without custom integration work per system.
Think of it like a USB standard for data. Before USB, every peripheral had its own connector. After USB, the peripheral and the device just needed to agree on one protocol.
In practical terms: a business could have an MCP server for their CRM, another for their ERP, and another for their file system. An MCP-compatible agent can discover what each server offers and call it — without the agent developer writing bespoke code for each integration.
What MCP Is Not
It is worth being precise about MCP’s current status. As of mid-2026, MCP is a standard with strong and growing adoption. The major model providers (Anthropic, OpenAI, Google) have moved toward supporting it, and a significant number of enterprise software vendors have built MCP-compliant interfaces. But many systems your business actually runs — particularly custom-built databases, heavily modified ERP instances, and niche line-of-business applications — still lack MCP server support and require custom integration work.
That means, in most real-world deployments, a mix is still necessary: MCP where it is available, custom tool definitions where it isn’t. Any vendor who tells you MCP eliminates all integration work is overselling it.
The Questions Buyers Must Ask
Understanding how agents use tools is not just academic. It changes how you evaluate vendors and what you put in a contract. Here are the questions that actually matter:
How does the agent reach my specific systems? Not “can it integrate with CRMs” — ask: “How does it connect to my instance of HubSpot / SAP / Odoo, and who maintains that connection when we upgrade?”
Which tools does it use, and what permissions does each tool have? A tool that can only read data has a fundamentally different risk profile from one that can write or delete. You should see a tool manifest — a list of what the agent can call and what scope each call carries. This is central to AI agent security and worth treating with the same rigour as access control in any other system.
Does it support MCP, and which of my systems have MCP servers available? If the answer is “we use MCP,” the follow-up is: “For which systems, specifically, and which integrations are still custom?” Honest vendors will distinguish the two.
What happens when a tool call fails? An agent that silently ignores a failed API call and continues reasoning is dangerous. You want to know: does it retry, surface the error, escalate to a human, or halt? The failure behaviour of tool calls is an underexamined part of most agent specifications.
How are tool credentials managed and rotated? Every tool call that touches a real system requires authentication. API keys and OAuth tokens age and need rotation. Ask who manages this and whether credential handling is automated.
An Illustration: What This Means for a Mid-Size Distributor
A wholesale distributor with 40 staff runs its business on a mid-market ERP, a spreadsheet-based quoting process, and a CRM that sales staff use inconsistently. They want an agent that can handle order-status queries from customers and flag reorder triggers to the purchasing team.
On paper, the use case is clear. In practice, getting there means:
- Building or sourcing MCP-compatible tooling for their ERP (or writing custom API wrappers if MCP support isn’t available in their version)
- Defining the exact scope of what the agent can read vs. write
- Setting up authentication flows the agent can use at runtime
- Testing edge cases — what happens when stock data is stale, when an order ID doesn’t exist, when the ERP API is down during business hours
None of this is insurmountable, but none of it is “just plug in an agent.” The integration layer is where the real engineering lives, and it is where the gap between a convincing demo and a reliable production system tends to appear. For more on what this integration work actually involves, see our guide to connecting AI agents to your CRM and ERP.
What Good Agent Architecture Looks Like Here
A well-built agent does not have tools bolted on as an afterthought. The tool layer is designed from the start with:
- Minimal privilege: each tool has the narrowest permission set that still allows the task
- Observable calls: every tool invocation is logged with its inputs, outputs, timestamp, and the agent’s reasoning step that triggered it
- Graceful degradation: the agent knows what to do when a tool is unavailable — which is often “ask the human” rather than guess
- Versioned interfaces: when an underlying API changes, the tool definition updates without requiring changes to the agent’s core reasoning logic
For a deeper look at how these components fit together, AI agent architecture, explained for decision-makers covers the broader system design.
Who Should Care About This Now
If you are evaluating an AI agent project and your answer to “how does the agent connect to our systems?” is “I’m not sure,” you are carrying technical risk that will materialise at implementation. That is not a reason to delay — it is a reason to ask the right questions earlier.
If you already have an agent in production that you didn’t build, this is a good moment to audit its tool manifest. What can it call? With what credentials? What are the failure modes? Most organisations running third-party agents have never reviewed this.
Talk Through Your Integration Requirements
At Orange ITS, we design agents where the integration layer is a first-class concern — not an afterthought. Our AI agent development service covers the full stack: tool design, MCP adoption where it applies, custom integration where it doesn’t, and the credential and observability infrastructure that keeps it reliable in production.
If you’re assessing an agent project and want a second opinion on whether the integration approach is sound — or if you’re starting from scratch and want to avoid the common traps — book a 30-minute call with our team. We’ll walk through your systems landscape and give you a direct assessment of what an agent would actually need to connect to them.