What is an MCP server? A plain-language explainer with an example

An MCP server is a small program that gives an AI assistant a set of things it can do. It might let the assistant search your GitHub repositories, read tickets in Jira, query a database, or control a browser. The assistant discovers what the server offers, calls it when useful, and shows you the result.

"MCP" is the Model Context Protocol, the open standard that defines how this conversation between assistant and server works. If you want the full picture, start with our complete guide to MCP. This page answers the narrower question: what is a server, concretely?

What an MCP server does

Every MCP server does three things.

1. Advertises capabilities. When an assistant connects, the server lists its tools (actions), resources (data) and prompts (templates). Each tool comes with a name, a description written for the model, and a schema for its inputs.
2. Executes requests. When the model decides to use a tool, the assistant sends a request to the server. The server does the work, usually by calling an underlying API, and returns the result.
3. Stays out of the conversation. The server never sees the whole chat. It sees only the requests sent to it. That keeps servers simple and limits the damage a misbehaving one can do.

A concrete example

Say you use Claude Code and want it to work with your team's issues in Linear. Linear provides an MCP server. When Claude Code connects, the server reports tools such as:

You then type: "Find the open bugs assigned to me and create a branch name for the oldest one." The model calls list_issues with the right filters, reads the result, picks the oldest, and answers. It never needed to know Linear's REST API. The server handled that.

The request that went over the wire is plain JSON-RPC:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "list_issues",
    "arguments": { "assignee": "me", "state": "open", "label": "bug" }
  }
}

Local vs remote servers

There are two ways a server can run.

Local (stdio). The assistant starts the server as a child process and talks to it through standard input and output. Nothing leaves your machine except whatever the server itself decides to call. This is the typical setup for filesystem access, local databases, and developer tools. It also means the server runs with your user account's permissions.

Remote (Streamable HTTP). The server runs somewhere else, on the vendor's infrastructure or your company's, and the assistant talks to it over HTTPS. Authentication is OAuth 2.1. This is what GitHub, Atlassian, Linear, Notion, Sentry and most SaaS vendors provide now, because it means no installation and central control over who can connect.

For a company, remote servers are easier to govern and local servers are easier to abuse. A common policy is: remote servers from an approved list, local servers only from a short internal catalogue.

How to connect one

The mechanics differ slightly per client, but the shape is the same everywhere.

Claude Code. From the terminal:

# Remote server over HTTP
claude mcp add --transport http linear https://mcp.linear.app/mcp

# Local server started as a process
claude mcp add --transport stdio filesystem -- npx -y @modelcontextprotocol/server-filesystem ~/projects

Inside a session, /mcp shows the connected servers and starts the OAuth login for remote ones. Servers can be scoped to you, to a project (a committed .mcp.json file), or to your user across all projects.

Claude Desktop and claude.ai. Remote servers are added as connectors in settings. Local servers on desktop are declared in a JSON config file.

Cursor and VS Code. Both read an mcp.json file in the project or user settings, with the same command-or-URL structure.

Once connected, the assistant lists the tools and asks for permission the first time it wants to use one. Read-only tools are usually approved once; write tools are worth approving per call until you trust the server.

When to write your own

Most teams never need to write a server, because the systems they use already have one. You write your own when:

• the system is internal and has no public server (an ERP, a data warehouse, a customer portal);
• the public server exposes too much and you want a narrower, safer surface, for example read-only access to three specific tables;
• you want to combine several systems behind one set of tools that match how your team actually works.

The official SDKs (TypeScript and Python are the most used) make a minimal server a hundred lines or so. A tool definition in the TypeScript SDK looks like this:

server.registerTool(
  "get_customer",
  {
    description: "Fetch a customer record by customer number.",
    inputSchema: { customerNo: z.string() },
  },
  async ({ customerNo }) => {
    const c = await crm.customers.get(customerNo)
    return { content: [{ type: "text", text: JSON.stringify(c) }] }
  },
)

The hard part is not the code. It is deciding what to expose, how to authenticate, and how to keep the model from being tricked through the data it reads. Our MCP security best practices cover that.

What a company should know

Three things change when MCP servers go from one laptop to a whole organisation.

First, the list of servers becomes an attack surface. Anyone can publish a server, and the model trusts tool descriptions. A central allowlist is the minimum.

Second, the data path matters. A remote server hosted outside the EU receives whatever the model sends it. For companies under GDPR that needs a legal basis, not just a security review.

Third, you need the log. Which user, which assistant, which server, which tool, which arguments, when. Without it, incident response is guesswork.

The usual answer is an MCP gateway in your own region that all assistants go through. Walma AI Hub provides that layer inside the customer's Azure tenant, and hosts the MCP servers the company approves next to it. If you are planning a rollout, book a walkthrough.