What is an MCP server, and when does a business need one?

Anthropic's Claude Code documentation describes the Model Context Protocol as an open source standard for AI-tool integrations, and says MCP servers give Claude Code access to your tools, databases and APIs. In plain terms, it is an agreed way for an AI application to ask a server 'what can you do?' and then call it. The AI application is the client. The server is a small program that sits in front of your system and answers.

The reason it exists is repetition. Without a standard, every AI application needs its own custom connection to every system. With one, you write the connection to your system once, as a server, and any application that speaks the protocol can use it. Anthropic's documentation uses the example of connecting an issue tracker, a monitoring dashboard or a database so the assistant can read and act on that system directly instead of working from whatever you paste into a chat.

Two limits on what we say here. The protocol is still evolving and Claude Code's own documentation refers to protocol revisions and a newer client runtime, so check the current specification at modelcontextprotocol.io before you build. We could not read that site from our environment when writing this, so the protocol facts below rest on Anthropic's Claude Code and API documentation, linked under Sources. And we are not an Anthropic partner; nothing here is endorsed by Anthropic.

Three kinds of thing. Claude Code's documentation refers to all three when it describes a server's capabilities: tools, prompts and resources, which a client discovers by asking the server to list them.

In practice most business servers are mostly tools. That is also where the design effort belongs, because a tool's name, description and inputs are all the model knows about what it may do. Anthropic's tool-use documentation describes the mechanism: Claude decides when to call a tool from the request and the tool's description, and returns a structured call that your application executes. The model asks. Your code does the work, and your code is where the checks live.

A server can also change what it offers while a client is connected. Claude Code's documentation says a server can update its tools, prompts or resources and notify the client, which then refreshes. That is convenient for your own server and a reason not to connect servers you do not control.

Claude Code's documentation describes two main shapes. A local server runs as a process on the machine of the person using the client, over the standard input and output (the 'stdio' transport). A remote server runs elsewhere and is reached over HTTP, which the documentation recommends for remote servers; an older SSE transport is described as deprecated.

For a business, the rule of thumb is simple. Local is for a developer experimenting. Anything that touches shared business data should run as a remote server you control, so credentials sit in one place, access is per person and revocable, and there is one log. This is the same pattern we used on the fleet order automation, where the monday.com token is account-wide and reaches commission data, so it lives in exactly one service and the front end never sees it. An MCP server is that boundary with a protocol on the front: the broad credential stays behind it, and the model is only handed narrow tools.

Start from the job, not the protocol. The question is whether a model has to choose its own actions among several systems, or whether you can write the steps down. Our article on AI agents for operations makes the same cut: most operations problems are workflows with one model-shaped step, and an agent buys unpredictability you then have to engineer back out.

Some automation platforms and SaaS vendors now offer MCP connectors of their own. We have not compared them, and what they expose changes, so read the current documentation for any you consider and apply the checks in this article to it.

Two separate questions, and an MCP server has to answer both. Authentication: who or what is this client? Authorisation: what is it allowed to do with each tool and each record? A server that answers the first and skips the second is a locked front door with every room open.

• Use the sign-in the protocol and your client support. Claude Code's documentation says it supports OAuth 2.0 for remote servers and flags a server as needing authentication when it answers 401 or 403. It also accepts a static token in a request header for simpler cases. Prefer per-user sign-in over one shared secret, so you can tell people apart in the log and revoke one without breaking everyone.
• Keep the broad credential inside the server. The server holds the key to the CRM or database. The model never sees it and cannot be talked into printing it, because it is not in the conversation.
• Authorise per tool and per record, in the server, not in the tool description. A description that says 'only use for the user's own customers' is a request. A query that filters by the signed-in user's permissions is a rule.
• Give each agent its own identity and its own narrow scope. An agent that triages inbound mail needs different access from one that reconciles payments. One credential for all of them means one compromised agent reaches everything.
• Do not commit secrets. Claude Code's project file, .mcp.json, can be shared through version control and supports environment-variable expansion, so a token can be referenced instead of pasted.

On the client side, administrators have levers too. Claude Code's documentation describes three scopes for server configuration (local, project and user), an approval prompt for project-scoped servers in interactive sessions, and managed configuration to restrict which servers an organisation's users may run. It also notes that non-interactive runs and cloud sessions load project-scoped servers without that prompt. So review a repository's .mcp.json like code, because in an automated run nobody is asked.

Split tools by consequence and widen in stages. The same rule sits behind our AI agents article: read tools are given freely, write tools either do not exist or create a proposal that waits for a person.

That is also why shadow mode matters. On the fleet order automation, the allocation and SLA layer shipped behind a flag that logged what it would have done without doing it, and comparing that with the manual process for real orders is what made the cutover uneventful. A write tool on an MCP server can run the same way: record the proposed call, compare with what a person did, and enable the real write later.

Audit logging

Log every tool call with who or what called it, the tool, the arguments, a summary of the result, the time and whether it succeeded, in a store the agent cannot edit. On the trading ERP, every write appends a field-level entry to a table staff can insert into and read but never update or delete, so the trail cannot be rewritten through the API. Do the same for the server. If a figure is queried months later, you want to know what was asked and what came back, not what the model said it did.

Over-broad tools

The commonest mistake is a tool that is too general, because it was quick to write. A run_sql tool, a call_api tool that takes any URL, a tool that accepts a free-text 'action' parameter. Each one gives the model, and anyone who can influence the model, the full power of the credential behind it. Prefer one tool per intent with typed inputs: find_order, list_overdue_invoices, create_draft_reply. Validate the inputs on the server. Return only the fields the job needs, and keep results small, since Claude Code's documentation says it warns about, and by default limits, very large tool output.

Prompt injection through tool results

Whatever a tool returns goes into the model's context, and some of it is text written by outsiders: an email body, a supplier's PDF, a web page, a customer's note. If that text contains instructions, the model may follow them. Anthropic's Claude Code documentation warns that servers which fetch external content can expose you to prompt injection, and its security page says that while the protections reduce risk, no system is completely immune. Anthropic's guidance for applications recommends labelling untrusted content as such, keeping it out of the system prompt, limiting the model's access to sensitive data and actions, and testing with hostile inputs. Our companion article on securing AI agents covers those controls in detail.

For an MCP server the practical consequence is this. The more your tools can read untrusted content, and the more they can do, the more an injected instruction can achieve. A server that reads inbound email and can also send email, on the same credential, has both halves of the problem. Split them: a reading server with no send tool, and any outbound action behind a proposal and a person.

Servers you did not write

Anthropic's security page encourages writing your own servers or using providers you trust, and says Anthropic reviews connectors against listing criteria for its directory but does not security-audit or manage any MCP server. Treat a third-party server like a third-party dependency with access to your data: read what it can do, check the scopes it requests, and prefer one you can pin or host.

1. 01Pick one question people ask repeatedly across one system, such as 'where is this order and what is its status?'. Not 'connect everything'.
2. 02Write the three or four tools that answer it, each doing one thing with typed inputs and small outputs. Write the description as if for a new colleague.
3. 03Put the server in front of a staging copy or a read-only database role. The model never gets the underlying credential.
4. 04Add per-user sign-in, an allowlist of who may connect, and the append-only log, before the first real query.
5. 05Use it yourselves for a while. Read the log. Look for questions the tools cannot answer and tools being called with arguments you did not expect.
6. 06Move to live data through narrow views only when the log looks the way you intended. Add proposals for writes after that, not before.
7. 07Write down who owns the server, how to disable it quickly and how to rotate its credential.

A caution about our own track record. We have not published a case study of an MCP server running in production for a client, and we do not claim one. What we can point to is the pattern it relies on: the credential boundary and shadow mode on the fleet order automation, and the append-only audit trail and model-proposes, person-confirms design on the trading ERP, where Claude reads supplier invoices. Our Claude platform page describes operations agents with a short list of narrow tools, usually exposed through an MCP server over your own systems, as something we build; our AI integration page covers the wider work.