What Is MCP? How AI Connects to Your Business Systems

01

The difficult part is connecting AI to the work

An AI assistant can write a convincing customer update in seconds. That does not mean it knows which customer the message concerns, whether their documents are complete, who owns the case or whether anybody has approved the next action.

To help with real work, the assistant needs controlled access to the systems where that information lives. It may need to read a customer record, inspect a case, find missing documents, create a follow-up task and prepare a draft message. Traditionally, each connection is a custom integration with its own code, authentication, data shapes and error handling.

Model Context Protocol, usually shortened to MCP, is an open standard intended to make those connections more consistent. It gives AI applications a shared way to discover available context and tools instead of every application inventing a different connector format.

That is useful plumbing. It is not permission to connect an AI model to everything the company owns. The useful question is not only whether an MCP server can expose a capability. It is whether that capability is narrow enough, authorised for the current user and safe to invoke in the current situation.

02

MCP is a protocol, not an AI model

A protocol is an agreed way for different software to communicate. Email has protocols. Web browsers and servers use protocols. MCP applies the same general idea to AI applications and the external systems they may need to use.

The official MCP documentation describes it as an open source standard for connecting AI applications to external systems. A compatible AI application can ask an MCP server what it offers, understand the shape of each capability and call an approved tool using a predictable message format.

MCP does not make the model more intelligent. It does not train the model, decide the business rules or guarantee that an answer is correct. It gives the application a standard connection through which relevant information and actions can be made available.

That distinction matters commercially. A company may gain reuse because the same well-designed MCP server can work with more than one compatible AI client. It will still need to design the underlying workflow, permissions, validation, monitoring and support around the connection.

03

The host, client and server each have a different job

The names become easier when they are attached to a real example. Imagine an operations assistant that helps a member of staff prepare a customer case for review.

The host is the AI application the person is using. It manages the conversation, user consent, security policy and the connections available in that session. The MCP client lives inside the host and maintains a connection to one MCP server. The server exposes a focused set of capabilities from the case management system.

A business may run several servers. One could expose customer and case information, another could work with the document store and another could create tasks. The MCP architecture is deliberately composable. The official specification also keeps each client connected to one server, which helps the host maintain clear boundaries between those connections.

The external system does not disappear. The MCP server normally calls an existing API, database service or application layer. It should respect the same tenant boundaries, permissions and business rules as any other trusted interface rather than becoming a side door around them.

04

Resources, tools and prompts are not the same thing

An MCP server can make different kinds of capability available. Resources provide context that an application can read, such as a policy, document or case summary. Tools allow the model to request an operation. Prompts provide reusable interaction templates that the user or host can choose.

For the case review example, a resource might provide the current validation policy. A read-only tool might list missing documents for one case. A low-risk write tool might create a draft follow-up task. A more sensitive tool might send a customer message or change the status of a case.

Putting all of those behind the word tool hides an important difference. Reading a summary, creating a reversible draft and sending an external communication carry different consequences. They should not inherit the same approval rules merely because they travel through the same protocol.

Good tool names and schemas help. A focused tool such as list_missing_case_documents is easier to understand, authorise and audit than a generic run_database_query tool. The server should expose useful business operations, not unrestricted access to the machinery underneath them.

05

Start with the smallest useful capability

The table below shows how I would separate capabilities before giving an AI assistant access to an operational system. The default control should become stronger as the consequence of a mistake increases.

These are starting positions, not universal rules. A draft task in one company may be harmless and in another may trigger a regulated workflow. The control has to reflect what the action really does.

06

MCP does not remove the need for permissions

The host decides which servers are available and should preserve the identity and authority of the person using the application. The server then needs to enforce the permissions that apply to that person, organisation and record.

Least privilege is the useful default. Give the connection the smallest set of scopes it needs for the first task, then request an additional scope only when a real capability requires it. A reporting assistant does not need the ability to edit customer records simply because the underlying API supports both operations.

The MCP security guidance explicitly warns against token passthrough. A server should not accept a token intended for another service and forward it without validating that the token was issued for the server. That shortcut can bypass audience checks, muddle audit trails and enlarge the damage caused by a leaked credential.

Every call should also be checked at the server boundary. Validate identifiers and arguments, restrict result sizes, remove fields the model does not need and record who requested the action. The model proposing a tool call is not evidence that the user is authorised to perform it.

07

Treat instructions inside data as untrusted

An assistant may read an email, uploaded document, web page or supplier response before deciding which tool to use. Any of that content could contain text that looks like an instruction to the model. This is prompt injection, and connecting tools makes the consequence more serious than producing an odd sentence.

A customer attachment cannot grant itself permission to send an email, reveal another customer's record or change a payment. Data may influence the content of a decision, but it must not define the authority available to make that decision.

Keep tool descriptions and server metadata under trusted control. Filter the tools available for the current role and task. Require a clear preview and human approval before external, financial, destructive or difficult-to-reverse actions. Check the final arguments rather than approving a vague intention several steps earlier.

Approvals are not a nuisance to remove from every workflow. Placed at the point of consequence, they allow the assistant to perform the time-consuming preparation while a person retains responsibility for the sensitive action.

08

Better context can still produce a wrong answer

MCP can give an AI application access to fresher and more relevant business information. That can reduce the need to paste data into a chat and may make a response more useful. It does not guarantee accuracy.

The model can misunderstand the question, choose the wrong tool or interpret a correct result badly. The tool may return stale information. The server may contain a bug. A user may ask for a case using the wrong reference. The external system may be unavailable halfway through a workflow.

Design the response for those realities. Show which records were used, make uncertainty visible, return clear errors and avoid presenting a draft as a completed action. For important decisions, the person reviewing the output needs enough evidence to check it rather than being asked to trust a confident paragraph.

Observability matters here. Record tool discovery, calls, arguments appropriate for the audit policy, results, failures, approvals and the final business action. Without that trail, an AI integration becomes harder to support precisely when it begins doing useful work.

09

MCP complements APIs rather than replacing them

A good MCP server often sits on top of an existing API or application service. The API remains responsible for stable business behaviour, permissions and data integrity. MCP describes those useful capabilities in a form an AI host can discover and call.

MCP is attractive when several compatible AI clients may need the same focused capabilities, when the team wants standard discovery or when an existing MCP ecosystem already covers a useful system. A well-designed server can reduce repeated integration glue across those clients.

A direct API integration or ordinary function call may be clearer when one application needs one narrow connection and there is no realistic need for interoperability. Adding a protocol layer is not automatically simpler. Remote MCP calls also add network latency, failure modes and another service to operate. Tool list caching can help performance, but changes then need a clear invalidation strategy.

Choose the boundary that makes the system easiest to understand and control. MCP is an option for standardising an AI-facing interface. It is not a requirement for every piece of AI automation.

10

Build the first MCP connection as a controlled product feature

Start with one useful, read-only job. The case review assistant could fetch one case summary and list its missing documents. Use the identity of the signed-in staff member, enforce the existing tenant and role permissions, and return only the information needed for that review.

Next, add one reversible action such as preparing a follow-up task. Give it a narrow schema, validate every field, log the result and make the new task visible in the ordinary application. Test what happens when the case does not exist, the user lacks permission, a result is too large or the underlying system is unavailable.

Only then consider an action with an external consequence. Put approval immediately before the send, status change or financial action. Show the person exactly what will happen and preserve the evidence used to prepare it. Run tests with misleading instructions inside documents and messages, not only tidy examples written by the development team.

The result should feel less dramatic than the demos suggest. The assistant gathers the right records, prepares the work and removes repetitive searching. The business application still owns the rules, and a person still approves the actions that deserve responsibility.

That is the useful promise of MCP. It can make the connection between AI and business software more reusable. Trust still comes from narrow capabilities, real permissions, visible approvals and an audit trail that survives after the conversation ends.

If you are considering an MCP server or a wider AI workflow, I can help map the operation, choose the smallest worthwhile capability and build the controls around the systems your team already uses.