MCP explained: how AI agents safely use your internal tools

MCP AI agents are agents that reach your systems through the Model Context Protocol rather than through ad hoc integrations. The protocol, published by Anthropic as an open standard and adopted across the major model vendors and agent frameworks, defines how a model-side client discovers and calls tools that a server exposes. For a business, the useful part is not the wire format. It is that MCP forces you to describe every action an agent may take as a named, typed, scoped tool, in one place, reusable by any agent on any model.

This article explains what MCP is, how it changes tool calling from a per-project chore into an asset, what an MCP server for an internal system contains, and the security design that makes "agents can act on our systems" a sentence a CISO can accept.

What the Model Context Protocol is and why it matters

Before MCP, each agent project wrote its own tool definitions in its own framework's format, wired to its own credentials. A second agent on the same system repeated the work. Switching model vendors meant rewriting the tool layer. Security reviews had to inspect each integration separately.

MCP separates the two sides. An MCP server sits in front of a system, whether a CRM, an order database, a ticketing tool or a calendar, and publishes a list of tools with names, descriptions, input schemas and output schemas. An MCP client, embedded in the agent runtime, discovers those tools and calls them. The specification is open and model-agnostic, so the same server serves an agent built on OpenAI, Anthropic, Google or an open-weight model. That matters for our routing stance: evals decide which model runs each role, and the tool layer does not change when the answer changes.

The protocol also covers resources (read-only context such as a document or a record) and prompts (reusable templates), but tools are where the safety design lives, and they are the focus here.

AI tool calling: before and after MCP

What an MCP server for an internal system contains

MCP server development for a business system is mostly contract design. A server for an order system might expose four tools: look up an order by ID for a given customer, list a customer's recent orders, update a delivery address, and issue a refund up to the order value. Each has a schema for inputs and outputs, a description the model reads to decide when to use it, and a scope that says who may call it and with what limits.

Three design rules keep servers safe. First, tools are narrow. "Query orders" is not a tool; "look up order by ID for this customer" is. Second, tools are typed. Free-text inputs are limited to fields that genuinely need them, and outputs are structured so the agent cannot be fed instructions hidden in a response. Third, tools that change state take an idempotency key, so a retried call after a timeout does not repeat the action. The reasoning behind these rules is in How to build an AI agent that is safe to run unattended.

Scoped permissions: the server, not the model, decides

The agent never holds a database credential. The MCP server holds one, scoped to the least access its tools need, and every call carries the identity of the calling agent and, where relevant, the end user or customer on whose behalf it acts. The server checks both: is this agent allowed to call this tool, and is this user allowed to see or change this record. A support agent's session for customer A cannot look up customer B's order, however the prompt is phrased, because the server refuses.

Limits live here too. A refund tool enforces the per-action and per-period caps; anything above them returns a structured "requires approval" response that the agent routes to a person. Policy is enforced at the boundary and the prompt merely describes it. The approval design is in Policy-gated actions.

Audit and observability

Because every action passes through the server, the server is the natural audit point. Each call is logged with the tool, the arguments, the caller, the user, the result and the latency, and correlated with the agent run that made it through a trace identifier. Investigating a complaint means querying the server log, not reconstructing the model's reasoning. The log is also the source of the tool-call expectations in the evaluation suite: a scenario asserts not just the outcome but which tools were called with which arguments. Metrics built on this are described in How to measure an AI agent.

Where MCP fits in a multi-agent system

In a planner, worker and reviewer design, each worker connects to the MCP servers its job needs and no others. The extraction worker sees the document store; the payments worker sees the payments server; the planner sees neither. Because tool lists are discovered at runtime, adding a tool to a server makes it available to the right workers without redeploying the orchestrator, and removing one revokes it everywhere at once. This is how the "five tools or fewer per worker" rule from Multi-agent systems explained is enforced in practice rather than by convention.

Mistakes to avoid

• Wrapping a whole API as one tool. A tool that accepts an arbitrary endpoint and payload is a database connection with extra steps.
• Trusting tool descriptions from third-party servers. A description is content the model reads. Treat external MCP servers as untrusted until reviewed, and never let them describe tools that touch your systems.
• Returning raw records. Outputs should contain the fields the task needs, not every column, and never text that looks like instructions.
• Skipping the caller identity. A server that cannot tell which agent or user is calling cannot enforce scope.
• Running servers with admin credentials for convenience. Least privilege per server, per tool.
• No idempotency on writes. Retries will happen; make them safe.

A worked example

A direct-to-consumer brand wanted a WhatsApp agent that could check orders, arrange exchanges and process returns, and a separate personalisation service that read purchase history. Both needed the order system. Rather than two integrations, one MCP server exposed scoped tools over orders, stock and returns. The WhatsApp agent's session carried the customer's verified identity, so lookups were confined to their own orders; returns above a value threshold returned a requires-approval response that went to support staff.

The personalisation service used the same server's read-only tools with a different scope. When an exchange tool was added because shadow mode showed the agent could not see warehouse stock, it appeared to the WhatsApp agent without a redeploy. The personalisation and WhatsApp agent case study describes the outcome; the build is a customer service agent on a shared tool layer.

Team and timeline

An MCP server over one internal system is typically one to three weeks for a backend engineer working with your system owner: contract design first, then implementation, scope checks, logging and a direct test suite. This is priced under API development and integrations from $7,000 or ₹4.4 lakh, and is included in the scope of a multi-agent system from $24,500 or ₹16 lakh, where several servers are usually needed. For teams that must keep everything inside their own network, the servers run alongside the models under private agentic AI. Prices are on the pricing page, and clients own the servers, schemas and documentation outright.

Before you start: a checklist

• List the systems agents need and the narrowest actions required from each
• Write each tool's input and output schema before any code
• Decide how caller identity and end-user identity reach the server
• Set per-tool limits and the requires-approval response for anything above them
• Assign a least-privilege credential per server
• Add idempotency keys to every state-changing tool
• Plan logging with a trace identifier shared with the agent runtime
• Review any third-party MCP server before an agent may connect to it

Glossary

• MCP server: a service that publishes tools, resources and prompts for agents to use
• MCP client: the component in an agent runtime that discovers and calls tools
• Tool: a named, typed, scoped action an agent may call
• Resource: read-only context a server exposes, such as a record or document
• Scope: the rule for which callers may use a tool and with what limits
• Idempotency key: an identifier that makes a retried tool call safe
• Trace identifier: the ID that links tool calls to the agent run that made them

Related reading

AI agent orchestration covers where tool calls sit in a durable workflow, AI agents vs RPA covers exposing legacy bots as tools, and the Model Context Protocol specification is the primary source for the protocol itself.

Describe every action as a scoped tool, put the permissions in the server, and the question "can the agent do that?" always has a written answer.