MCP server

How an MCP server works

An MCP setup has three roles. The host is the AI application that starts connections. The client is a connector inside that host. The server is the service that provides context and capabilities 2. They exchange JSON-RPC 2.0 messages over a stateful connection 2.

A server can offer three kinds of features. Resources are context and data for the user or the model to use. Prompts are templated messages and workflows for users. Tools are functions for the model to execute 2. For a data service, tools are the feature that matters most, because the useful action is a call that fetches or checks data.

A session follows a loop. The client connects, and the two sides negotiate which capabilities each supports 2. The client learns which tools the server offers. When a user asks a question that needs outside data, the model picks a tool, the client sends the call, and the server returns a result that the model reads before it answers.

The specification puts consent in the host. Hosts must obtain explicit user consent before invoking any tool, and before exposing user data to servers 2. A server that returns paid or personal data relies on the host to ask the user first.

Every connection has an MCP client on the other end, and each callable function on the server is an MCP tool. The protocol as a whole is covered under Model Context Protocol, and the model side of a call is tool calling.

Types of MCP server

MCP servers come in two deployment shapes, set by the transport they use.

A local server runs on the user's own machine and talks to the client over stdio, which means standard input and standard output. Under the specification, a server on the stdio transport should not use the protocol's authorization flow and should retrieve credentials from the environment instead 3. Each user who installs it has to hold those credentials on their own machine.

A remote server runs as a web service, and the client reaches it over an HTTP-based transport. For HTTP-based transports the specification defines an authorization flow, and a protected server acts as an OAuth 2.1 resource server while the client acts as an OAuth 2.1 client 3. The flow is based on the OAuth 2.1 draft and related OAuth RFCs 3. The user signs in and approves access, and the client holds a token instead of a pasted key.

The choice affects setup and access more than features. A remote server can be updated in one place and shared by every user who connects to it. See remote MCP server and MCP OAuth for the details of each.

Example of an MCP server

The RichAPI MCP page documents a remote server and its setup in three steps 4. The server URL is https://mcp.richapi.ai/mcp 4. The user creates an account, pastes that URL into an MCP client, and signs in when the client opens RichAPI, then clicks Allow, with no API key to copy 4. The page states that the same URL works in Cursor, Windsurf and any other client that supports remote HTTP MCP 4.

That setup maps onto the protocol. The URL points the client at a remote server on an HTTP transport. The sign-in and Allow step is the authorization flow, which is why no key sits in a config file.

Once connected, the user works in plain language. One prompt on the RichAPI page reads as follows 4.

@richapi verify these emails [paste] and split them into valid / risky / invalid. Cost me as little as possible.

The model reads the request, picks the matching tool, and the client sends the call to the server. The page states that each prompt shows a cost summary when it finishes, including what was run and the credits used 4. Email verification through the server costs 2 credits per email 4. The cost summary is the record a user needs to audit what the assistant did on their behalf. The user can also check it against the credit balance in their account.

MCP server vs MCP client

Both sit on the same connection and play opposite roles. The client is a connector inside the host application, and the server provides context and capabilities 2. Anthropic's launch post framed the split from the developer side 1. Developers can either expose their data through MCP servers or build AI applications, the MCP clients, that connect to those servers 1. In practice the split decides who builds what. A company that wants its data available inside AI assistants builds one server. Each host that supports MCP ships its own client, so one server can work across several hosts. The host asks the user for consent before a tool runs, and the server decides which tools to offer and what each one returns 2.