What Is an MCP Server? A Plain-Language Guide

Short answer: an MCP server is a small program that exposes a tool's capabilities to AI agents in a standard format. It tells any connected agent what it can do, then executes those actions when the agent asks, so the agent can search a catalog, create a task, or fetch a record without custom integration code.

MCP is the Model Context Protocol, an open standard for connecting AI agents to tools. Before it, every agent product needed hand-built glue for every tool it touched: one integration for the CRM, another for the ticket system, a third for the calendar. A Model Context Protocol server replaces that glue. A vendor writes one server, and every MCP-capable agent (Claude Code, Claude Desktop, Cursor, and a growing list of others) can use it on day one.

How an MCP server works

An MCP server has three jobs: advertise, execute, respond.

It advertises its tools. When an agent connects, the server hands over a catalog: each tool gets a name, a plain-language description, and a schema for the inputs it accepts. The model reads that catalog the way you read a menu. This self-description is the core trick of the protocol. Nobody writes per-tool integration code, because the server explains itself in a format the model already understands.

It executes calls. When the agent decides a tool fits the task, the client sends a call with arguments. The server validates them, does the actual work (usually by calling the underlying app's API or database), and handles authentication against the real service.

It returns results the model can read. The response comes back as text or structured data, lands in the agent's context, and the conversation continues with real information in it.

Servers run in one of two places. A local server runs as a process on your machine, which suits file access and developer tooling. A remote server lives at a URL and speaks Streamable HTTP, the natural shape for a SaaS product: nothing to install, connect and go.

If this sounds close to an ordinary API, it is, but the differences decide whether an agent can actually use the thing. We wrote up the full comparison in [MCP vs API](/blog/mcp-vs-api). The one-line version: an API needs a developer to read the docs and write code first; an MCP server describes itself to the model directly.

A concrete example: create_task

Say a project management app ships an MCP server. It advertises three tools:

• create_task: creates a task in a project. Inputs: project_id, title, and an optional due_date.
• list_projects: returns the projects you can access, with their IDs.
• list_tasks: returns open tasks, filterable by project.

You tell your agent: "add a task to send the Meyer invoice, due Friday." Here is the sequence.

Step 1: The model scans its catalog and matches your intent to create_task.

Step 2: It needs a project_id it does not have, so it calls list_projects first, spots a project called Invoicing, and takes that ID.

Step 3: It fills in the arguments (the title, the project_id, Friday's date) and the client sends the call. Most clients show you the call and ask before it runs, so you can check the details.

Step 4: The server creates the task through the app's real backend and returns the new task's ID and a link. Your agent confirms, and the task exists.

No integration code was written for this. The vendor built the server once; the agent worked out the rest from the descriptions. If you wanted an MCP server explained in one story, that is it: advertise, call, respond.

One server covers one tool

A single MCP server is one connection to one service. Your agent can connect several at once, and each adds its own tool catalog to the model's context. Two or three servers work fine.

Past that, two costs creep in. Every catalog gets loaded into context whether the task needs it or not, and the model has more near-duplicate tools to choose between. That is the problem an [MCP gateway](/blog/what-is-an-mcp-gateway) exists to solve: one endpoint that federates many servers behind a single catalog. Different product, different post; this article stays on single servers.

How to try an MCP server today

Step 1: pick a client. If you use Claude Code, Claude Desktop, or Cursor, you already have one. The MCP client is the agent-side half of the protocol, and it is built in.

Step 2: pick a server. You can [browse the curated directory](/discover) and filter for tools with MCP support. Or start with ours, since reads need no account: Tulimoa's directory server lives at https://mcp.tulimoa.com/mcp over Streamable HTTP. In Claude Code, one command connects it: claude mcp add --transport http tulimoa https://mcp.tulimoa.com/mcp. The [MCP page](/mcp) documents all five of its tools.

Step 3: ask something that needs it. Try "find me an EU-hosted helpdesk that supports MCP." Watch the agent pick search_listings, fill in the filters, and answer from live data. Once you have seen one tool call happen, the whole mental model clicks.

One note on versions: the MCP v2 spec went final in July 2026. Tulimoa's public server runs it alongside the earlier era, so older clients keep working and you can ignore spec versions while you learn.

Frequently asked questions

What is the difference between an MCP server and an MCP client?

The server is the tool side: it advertises capabilities and executes calls. The client is the agent side: it connects to servers, shows the model their catalogs, and forwards the model's calls. Claude Code and Claude Desktop ship with a client built in; vendors ship the servers.

Do I need to write code to use an MCP server?

No. Using one is configuration, not programming: you add the server's URL or install command to your client and start asking questions. Writing your own server is a coding task, but the official SDKs keep it small.

Do MCP servers cost money?

The protocol is open and free. Individual servers vary: some are free and need no account for reads (Tulimoa's directory server is one), while others require an account with the underlying product because the server acts on your data there.

Is it safe to connect an MCP server?

Treat it like installing an app: check who runs it and what permissions it wants. Read tools are low risk; write tools deserve a confirmation step before they run. We cover the practical checks, including why OAuth beats pasted API keys, in [MCP security basics](/blog/mcp-security-basics).