What is an MCP server? Uses and examples.

An MCP server is a program that gives AI applications a standard way to use one of your systems. MCP stands for Model Context Protocol, an open standard Anthropic introduced in 2024. The server wraps a CRM, ERP, document store or product API, and tells the AI application which actions it can take and which data it can read.

Any AI application that supports the protocol can then connect: Claude, ChatGPT or an agent your own team builds. Whether your organisation needs one depends mostly on how many AI tools have to reach the same systems.

MCP has three roles. The host is the AI application a person uses, such as an assistant. Inside the host, an MCP client holds the connection to one server. The server wraps one system and tells the client what it offers. Client and server exchange JSON-RPC messages, a plain format for requests and responses between programs.

The model reaches your systems only through that chain: it asks for a tool, the client sends the request and the server calls the system.

What a server exposes: tools, resources and prompts

• Tools are actions with typed inputs, such as searching orders or creating a ticket. The model decides when to call one.
• Resources are data the application can read, such as a file, a record or a database schema.
• Prompts are ready-made instructions for common tasks, such as summarising an account, that a user can pick.

Here is an illustrative tool definition, as a server lists it for the client. The model reads the description to decide when the tool fits, and the input schema defines a valid call:

{
  "name": "search_orders",
  "description": "Search one customer's orders by status. Read-only. Returns at most 20 orders.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string", "description": "Customer id from the CRM" },
      "status": { "type": "string", "enum": ["open", "shipped", "cancelled"] }
    },
    "required": ["customer_id"]
  }
}

Local and remote servers

A local server runs on the same machine as the host, which starts it and talks to it over standard input and output (stdio). A remote server runs on infrastructure you or a vendor host, and clients reach it over HTTP. Company systems usually get a remote server, which many users share and you secure in one place.

One exchange, step by step

1. 01When the assistant connects, the client asks the server which tools it offers (tools/list) and passes their names, descriptions and schemas to the model.
2. 02A user asks: "Which orders for this customer are still open?"
3. 03The model picks search_orders and fills in the customer id and the status open.
4. 04The client sends the call (tools/call). The server checks who the user is and whether they may see this customer's orders.
5. 05The server calls the order system's API and applies its own limits.
6. 06The server returns the result, and the model uses it to answer the user.

Companies use MCP servers in two ways: to let their staff's AI tools work with internal systems, and to let customers' agents work with their product. The first three examples below are illustrative, typical cases of internal use. The fourth is Moneyline, a live product we built.

Read-only lookups in an ERP or CRM

For example, account managers ask their assistant about a customer before a call. A server over the ERP and CRM offers read tools such as get_customer and list_open_orders, limited to the accounts that user may see. Nothing gets written, which makes this a good first server.

Search over a document store

A typical case: people have questions about contracts and procedures kept in a document management system. The server offers a search_documents tool that returns matching passages with a link to the source. The document system's permissions still apply, so a search only returns what the user could already open.

Creating and updating tickets, with approval

For example, an IT service desk lets an agent triage incoming requests. The server offers create_ticket and add_comment, with limits in the tool code: a fixed list of categories, and no tool for closing tickets. The agent prepares each change, a service desk employee approves it, and the server logs who approved what.

Your product as an MCP server: Moneyline

For a product, it works the other way: you publish an MCP server so customers' AI tools can work with it. Moneyline, which we built, is an open-source API that ingests, classifies, parses and enriches financial documents, live at moneyline.co (opens in a new tab). It ships an MCP server that exposes those capabilities as tools an agent can call.

The API, SDKs, dashboard and MCP server all call the same services underneath, so a developer calling an endpoint and an agent calling a tool get the same parsing.

An API integration is code a developer writes so one system calls another in a fixed way. An MCP server describes a system's actions so AI applications can discover them and a model can choose when to use them. It usually calls the existing API to do the work, so the API stays and gains a layer for AI tools.

The two live side by side: a nightly sync keeps using the order system's API, and the MCP server calls the same API when an assistant needs an order. Our explainer on what an API integration is covers that layer.

Securing an MCP server means deciding who can sign in, what each user may do through it, which actions wait for a person's approval and what gets logged. It also means treating everything a tool returns as untrusted input, and checking any third-party server before anyone connects it to company data.

Sign-in and per-user scopes

For remote servers, the MCP specification defines authorisation based on OAuth. The user signs in through your identity provider, the AI application receives a token for that user, and the server checks it on every call. Avoid a shared account with broad access, which every user of the assistant would inherit.

Give every tool a scope, such as crm:read or tickets:write, and check it per user. A sales rep's assistant then sees only that rep's accounts. A local server usually runs with an API key stored on the machine; give that key the narrowest rights available.

Read-only by default, approval before writes

Start with read tools, and add write tools one at a time, each as narrow as its task, such as add_comment(ticket_id, text). General tools such as run_query let the model do far more than any task needs. Put limits in the server code, where no prompt can change them: maximum amounts, allowed statuses, which records a tool may touch.

Actions that are hard to undo or leave your organisation, such as payments, customer emails and changes to records, need a named person's approval, recorded with the action. Some AI applications ask users to confirm tool calls, but people who confirm every call tend to stop reading, so keep this approval in your own system. Our article on human-in-the-loop AI agents covers approval checkpoints and risk tiers.

Log every tool call

Record the user, tool, arguments, result and time of every call, and send it to your existing monitoring. That log answers "who changed this record, and through which assistant?" months later. Add rate limits per user and per tool, so an agent stuck in a loop can't flood the system behind the server.

Treat tool output as untrusted input

Everything a tool returns reaches the model as text: an email body, a ticket, a fetched web page. That text can carry instructions aimed at the model, such as a ticket telling the assistant to export every customer record. This is prompt injection, and models can't reliably tell your instructions from instructions hidden in data.

• Enforce permissions in the server, so an injected instruction can only reach what the user could reach anyway.
• When a session reads untrusted content, put approval on tools that send data out, such as email.

Vet third-party servers

A server someone else wrote gives their code a path to your data. Before anyone connects one, check:

• Who publishes it. Prefer the server from the vendor of the system itself.
• What its tool descriptions say. The model reads them, so a malicious server can hide instructions there.
• What a local server can reach. It runs as a program on the user's machine, with that user's files and network access.
• Where a remote server sends your data, who hosts it and in which region.
• What changes on update. Pin the version and review changes to the tool list before rolling one out.

Use the vendor's MCP server when your system is a common product and the vendor publishes one that passes your checks. Build your own when several AI tools or teams need the same internal systems, or when you want customers' agents to use your product. When one application calls one API in a fixed way, a direct integration is simpler.

When the vendor's server is enough

A vendor's server is enough when the system is a standard SaaS product, the vendor maintains the server, and its tools and scopes cover what your people need.

When to build your own

• Several AI tools or teams need the same internal systems. You build the server once, and Claude, ChatGPT and your in-house agents share its tools, scopes and logs.
• The system is in-house or older software without an MCP server of its own.
• You need rules a generic server can't know: your approval steps, scopes per role, limits on amounts or records.
• You want customers' agents to use your product, as with Moneyline.

Our MCP server starter, open source on GitHub, shows the structure we start from: OAuth sign-in, a scope per tool, typed inputs, rate limits and an audit log of every call. If you want it built and run for you, see how we build custom MCP servers for internal systems and products.

When a direct integration is simpler

If one application calls one API, such as a nightly sync, or your team writes an agent in code that only needs two functions, define those calls in that application. An MCP server is one more thing to secure and maintain. Add one when a second AI tool needs the same access.

Is MCP only for Claude?

No. Anthropic introduced the Model Context Protocol as an open standard that any AI application can implement. ChatGPT can connect to MCP servers, and agents your team builds can connect through the protocol's open-source SDKs. Applications differ in which parts of the protocol they support, so check yours.

Does an MCP server replace an API?

No. An MCP server usually sits on top of a system's existing API and calls it to do the work. The API keeps serving your other integrations, and the MCP server describes selected actions that AI applications can discover and use.

Is an MCP server secure?

An MCP server is secure when its controls are designed in. The protocol defines OAuth-based authorisation for remote servers. Per-user scopes, read-only defaults, approval before write actions, a log of every tool call and vetting of third-party servers are up to whoever builds and runs it.

Do I need an MCP server for AI agents?

Not always. An agent needs tools, and when one agent works with a few systems you can define those tools in its own code. An MCP server pays off when several agents or assistants such as Claude or ChatGPT need the same systems. Our explainer on what an AI agent is covers the rest.