What is an MCP server? How MCP works, with a real example

Every AI client now has a settings page for MCP servers, and most explanations of what goes in it are either a protocol spec or a vendor pitch. This is the middle version: what an MCP server is, how a request travels from a chat message to your code and back, what people use MCP for, real servers you can connect today, and the exact config for Claude, Cursor, VS Code and ChatGPT. The worked example throughout is a jobs server, because job postings are the clearest case of data a model cannot know on its own.

What is an MCP server?

An MCP server is a program that exposes tools, resources and prompts to an AI model through the Model Context Protocol, an open standard published by Anthropic in November 2024. The model’s host application connects to the server, reads what it offers, and lets the model call its tools, so the same server works in any client that speaks the protocol.

The comparison that lands is a USB port. Before MCP, every AI product integrated with every data source separately: a Slack plugin for one assistant, a different Slack plugin for the next. With MCP the Slack side is written once as a server, and any host, Claude, Cursor, ChatGPT, VS Code or an agent you wrote yourself, plugs into it. The server can be a few hundred lines that run on your laptop or a hosted service that serves thousands of users; the client cannot tell the difference.

How does MCP work?

MCP works as a JSON-RPC conversation between a client, embedded in the host application, and a server. The client asks the server what it offers, the model decides to call a tool, the client sends the call, the server runs it and returns a result, and the model reads that result as context for its next reply. The pieces:

• Host and client. The host is the application the user talks to. It runs one client per connected server and decides which tool calls the model may make, usually with a permission prompt.
• Server. The program that exposes capabilities. It knows nothing about the model; it answers protocol methods such as tools/list and tools/call.
• Tools. Functions the model chooses to call on its own, each with a name, a description and a JSON schema for its arguments. This is what you want most of the time.
• Resources. Read-only content the host can attach to the context, such as a file or a document, picked by the user or the client rather than the model.
• Prompts. Reusable templates the user invokes, the slash commands in a client’s menu.
• Transports. stdio, where the host launches the server as a subprocess and talks over standard input and output, and Streamable HTTP, where the server is a web service at a URL. Local tooling uses stdio; anything backed by a hosted API uses HTTP.

Here is the whole loop with the JobsPipe jobs server. You type “find remote data engineer roles posted in the last two weeks” into Claude. On connection, the client already sent tools/list and received four tools, among them search_jobs with a schema that describes every filter. The model reads the description, decides the question needs live data, and emits a call:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "search_jobs",
    "arguments": {
      "job_title_or": ["data engineer"],
      "remote": true,
      "posted_at_max_age_days": 14,
      "limit": 10
    }
  }
}

The server turns the arguments into a POST /v1/jobs/search request against the API under your account, and returns the postings as a text block plus a structuredContent object with data and metadata. The model now has titles, companies, salary ranges, posting dates and the apply URL for each result and writes its answer from those rows instead of from memory. Nothing in the exchange is specific to Claude; Cursor or ChatGPT would send the same JSON.

Two details matter in practice. Tool descriptions are the routing logic: the model picks a tool from its description and schema alone, so a vague description means the tool is never called. And the server can return errors as results with isError: true rather than protocol failures, which is what lets a model recover from a bad argument instead of retrying the same call. Both are covered in the build tutorial.

What is MCP used for in AI?

MCP is used to give AI models access to data and actions they do not have on their own: live information after the training cutoff, private data behind a login, and side effects such as creating a ticket or running a query. The common patterns:

• Coding agents. Servers for the filesystem, git, GitHub issues and pull requests, browsers and documentation let an agent read and change a codebase and check its work.
• Live and domain data. Search, web fetch, and vertical feeds such as job postings. A model cannot know which roles opened this morning; a tool can. See the jobs server and the job-seeker setup in ChatGPT for job search.
• Company data. Databases, CRMs, wikis and ticketing systems, connected read-only first, so an assistant can answer from the real numbers rather than from what someone pasted into the chat.
• Automation. Payments, deployments and messaging, where the host’s permission prompt is the safety net between the model’s decision and the side effect.

MCP does not replace an API. A server is a thin layer over one, shaped for a model: fewer, better-described operations, results trimmed to what a model can use, and errors written as instructions. If you already have an API, the question is only whether the model-shaped layer is worth publishing so every client gets it for free.

MCP server examples

• Reference servers from the protocol maintainers: filesystem, fetch, git, memory, time and sequential-thinking. Small, stdio, and the fastest way to see the protocol working.
• GitHub: the official server for repositories, issues, pull requests and code search.
• Playwright: Microsoft’s browser automation server, which lets an agent drive a real browser through the accessibility tree.
• Cloudflare: hosted servers for Workers, KV, R2, D1 and observability, an early example of a vendor shipping MCP over HTTP.
• Stripe and Sentry: hosted servers over payments data and error monitoring respectively.
• Context7: current library documentation, which fixes the “model trained on last year’s API” problem for coding agents.
• JobsPipe: a hosted server at https://mcp.jobspipe.dev/mcp with search_jobs, detect_company_tech_stack, list_pricing_plans and search_documentation, over live postings from LinkedIn, Indeed, Greenhouse, Lever, Ashby, Workday and the other collected boards.

A longer, opinionated list is in the best MCP servers for real data. The test to apply to any of them: does it give the model data it could not otherwise reach, and are its responses shaped for a context window?

How to connect an MCP server to Claude, Cursor or ChatGPT

Every client wants the same two facts, the server’s URL (or the command to launch it) and how to authenticate. The JobsPipe server accepts a sign-in with your JobsPipe account when the client prompts, or a jp_live_ key in an Authorization header.

Claude Code, one command, or a project .mcp.json:

claude mcp add --transport http jobspipe https://mcp.jobspipe.dev/mcp

{
  "mcpServers": {
    "jobspipe": {
      "type": "http",
      "url": "https://mcp.jobspipe.dev/mcp",
      "headers": { "Authorization": "Bearer jp_live_..." }
    }
  }
}

Claude Desktop and claude.ai: Settings, Connectors, add a custom connector, paste the URL. The sign-in prompt appears on first use.

Cursor: the same JSON without the type field, in .cursor/mcp.json for a project or the global config for every project:

{
  "mcpServers": {
    "jobspipe": {
      "url": "https://mcp.jobspipe.dev/mcp",
      "headers": { "Authorization": "Bearer jp_live_..." }
    }
  }
}

VS Code: .vscode/mcp.json uses a servers key and a type of http:

{
  "servers": {
    "jobspipe": { "type": "http", "url": "https://mcp.jobspipe.dev/mcp" }
  }
}

ChatGPT adds remote MCP servers as custom connectors from Settings, Connectors, on the plans that expose developer mode for connectors. Give it the URL above and sign in when prompted. The menu location changes between releases, so check OpenAI’s current help page if the option is not where this post says.

A stdio server is added with the launch command instead of a URL, for example claude mcp add jobs -- bun run src/stdio.ts. Agents that have a shell can skip all of this: the /agents.md document walks an agent through getting a key, adding the server and installing the CLI on its own.