# Connecting AI agents to systems with MCP

> MCP (Model Context Protocol) is an open protocol that lets an AI agent connect to systems such as an ERP, a CRM or a document store through one standard interface. Built well, the agent sees only the tools it is allowed to use, every call is logged and write actions ask a person first. The security comes from how you design the server, not from the protocol alone.

URL: https://corrplus.net/blog/mcp-ai-agent-integration/
Updated: 2026-10-26
Corrplus Team

## 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](/glossary/model-context-protocol/) and [AI agent](/glossary/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](/solutions/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](/services/ai-governance/) 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](/solutions/customer-onboarding-automation/), 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](/industries/technology-software/) companies and for [manufacturing](/industries/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](/services/ai-agent-development/), and for the model and API layer see [LLM integration](/services/llm-integration/). If your agents will plan several steps on their own, our definition of [agentic AI](/glossary/agentic-ai/) is a useful companion.

## Frequently asked questions

### Do we have to change our ERP to add an MCP server?

No. The MCP server is a thin layer in front of the ERP. It calls the ERP's existing API or a database view and exposes the result to the agent as defined tools. The ERP, its users and its business rules stay as they are.

### Does using MCP make an agent secure?

Not on its own. The specification sets out security principles but states that the protocol cannot enforce them. Scoping permissions, validating inputs, human approval and logging are designed by the team that builds the server and the client.

### Should every integration use MCP?

No. If one application needs one API call, direct function calling is simpler. MCP pays off when several agents or clients will use the same tools and the set of tools will grow.

### What happens if the agent deletes the wrong record?

That is why deletes and other irreversible writes are either not exposed in the first release or require human approval on every call. Each tool call is logged with who, when and which parameters, so a mistake can be traced and reversed.

## Sources

- [Model Context Protocol, Specification (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28)
- [Model Context Protocol, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
- [Model Context Protocol, Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)
- [Model Context Protocol, Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)
- [OWASP GenAI Security Project, Top 10 for LLM Applications (2025)](https://genai.owasp.org/llm-top-10/)
- [Anthropic, Building effective agents](https://www.anthropic.com/research/building-effective-agents)