Connecting AI agents to systems with MCP

What does an MCP server actually give an agent?

An MCP server is a service that gives an AI application context and capabilities from outside systems. Under the specification, servers offer three core features: tools (functions the model can execute), resources (data and context for the model or the user to read) and prompts (templated messages and workflows offered to the user). Messages use JSON-RPC 2.0.

A concrete example: an MCP server for a manufacturer’s ERP could expose check_stock, order_status and create_purchase_request tools. The product catalogue or supplier contracts could be offered as resources. The agent lists the tools, decides which to call and summarises the result for the user.

For short definitions, see our glossary entries on Model Context Protocol and AI agent. The real value of MCP is the standard itself: the same server can be used from any client that speaks MCP. You do not rewrite the integration for every new agent.

When should you use MCP, a direct API call or a workflow tool?

Not every integration needs MCP. Anthropic’s guidance on agents makes the same point: start with the simplest solution and add complexity only when it is needed. The table compares four common patterns.

Aspect	Direct function calling	MCP server	Workflow tool (n8n, Make)	RPA
Reuse	Embedded in one application	Shared by several agents and clients	Reused inside flows	Tied to a screen script
Authentication	The application’s own key	OAuth 2.1-based authorization over HTTP	The tool’s credential store	A robot user account
Logging	You build it	Designed on server and client side	Flow execution history	Robot logs
Risk on write actions	Whatever the code allows	Bounded by tool definitions and scopes	Bounded by flow steps	Whatever the screen allows
Good fit	Single-purpose assistant with few tools	Growing tool set, several agents	Defined, predictable process	Legacy system without an API

In practice these patterns are combined. A process with defined steps, such as invoice processing automation, usually runs in a workflow tool, and the agent steps in only where judgement is needed (an invoice line that does not match, for example). MCP comes into its own when the agent must reach many systems under the same rules.

How do you set up authorization and least privilege?

The authorization part of MCP builds on the OAuth 2.1 draft for HTTP-based transports. Local (stdio) servers take credentials from the environment instead. The rules that matter most:

• Tokens must be issued for that server. An MCP server must not accept an access token that was not issued for it.
• Token passthrough is forbidden. The server does not forward the client’s token to the ERP. It uses a separate identity for the downstream system.
• Scopes start small. The security best practices recommend a minimal initial scope covering low-risk read operations, with targeted elevation when a privileged action is first attempted. Wildcard or “full access” scopes are listed as a common mistake.

On the business side this turns into concrete decisions. Who is the agent’s user in the ERP? Which company codes and warehouses can it see? Which tables can it write to? Restricting this with the ERP’s own role permissions adds a second line of defence in case the MCP layer has a bug. The agent should never have wider access than the employee whose work it supports.

Which controls stop prompt injection and excessive agency?

An agent may treat any text it reads as an instruction. A line hidden in a supplier email saying “cancel all open orders” can become a real transaction in an agent without controls. The OWASP 2025 list for LLM applications names these risks. The ones that come up most in agent integrations:

OWASP risk	What it looks like in an agent integration	Control
LLM01 Prompt injection	Hidden instructions in a document, email or tool output	Treat external content as data; put write actions behind human approval
LLM02 Sensitive information disclosure	The agent surfaces records the user should not see	Narrow scopes; filter tool output
LLM03 Supply chain	An unreviewed third-party MCP server	Use reviewed servers only; pin versions
LLM06 Excessive agency	The agent holds more tools and permissions than the task needs	Limit tools and scopes to the job
LLM10 Unbounded consumption	A looping agent making thousands of calls	Rate limits, step limits, budget alerts

The tools section of the specification is explicit about the server side too: servers must validate all tool inputs, implement access controls, rate limit invocations and sanitise outputs. Tool descriptions and annotations such as “read only” are to be treated as untrusted unless they come from a trusted server.

How do you design human approval and a step-by-step audit log?

The specification recommends it directly: there should always be a human in the loop who can deny tool invocations. The client should show which tools are exposed to the model and ask for confirmation before sensitive operations. A practical way to turn this into business rules is to sort tools by risk:

1. Read: stock, order status, customer record. Can run without approval, but is logged.
2. Reversible write: draft quote, purchase request, CRM note. The agent prepares it, the user approves with one click.
3. Irreversible or financial: payment, refund, record deletion, price change. Not exposed in the first release, or requires two approvals.

For the log, store for each call: on whose behalf, which tool, which parameters, the result, who approved it and when. The specification also advises clients to log tool usage for audit purposes. That log makes debugging easier and answers the “what did the agent do?” question that AI governance and compliance work will ask. If tools touch personal data, assess them under GDPR, and under KVKK (Türkiye’s data protection law) for Turkish data subjects, with your legal counsel.

Where should you start?

Pick one process and begin with read-only tools. During customer onboarding, for instance, an agent that lists the CRM record and the missing documents is useful without any write permission. Once it has been tested with real user questions, add reversible write tools. The same order works for internal tooling at technology and software companies and for manufacturing businesses where the ERP sits at the centre.

At Corrplus we start this work in discovery by drafting a tool list, a risk class for each tool and a permission matrix. In design we write down which actions need approval, where logs are kept and which model will be used. We then deliver in short cycles, with a working version at the end of each one. For the agent itself see AI agent development, and for the model and API layer see LLM integration. If your agents will plan several steps on their own, our definition of agentic AI is a useful companion.