Definition
An MCP server is a server that implements the Model Context Protocol, an open standard for connecting AI applications to external capabilities. It exposes tools, resources, and prompts that an MCP client, such as an AI agent, can discover and call in a uniform way. Over the Streamable HTTP transport, an MCP server can also be gated with x402 so callers pay per use.
In short, an MCP server is how you give an AI application access to external tools and data through a common protocol. Rather than building a one-off integration for each capability, you expose them through an MCP server, and any MCP client can use them the same way. That standardization is the point of MCP, and it is why MCP servers became a common building block for giving agents capabilities, and increasingly a thing worth charging for.
What MCP is
MCP, the Model Context Protocol, is an open standard for connecting AI applications to external tools and data. It defines how a client, an AI app or agent, and a server, a provider of capabilities, talk to each other: how the client discovers what the server offers, how it calls a tool, and how results come back. Because it is a standard, any compliant client can work with any compliant server.
The problem MCP solves is integration sprawl. Before a common protocol, giving an AI app access to a new tool or data source meant a bespoke integration, and every app reinvented the wiring. MCP replaces that with one interface: build an MCP server once, and any MCP client can use it. This is analogous to how a common protocol let any web browser talk to any web server, and it is why MCP spread quickly as a way to extend what AI applications can do. The MCP server is the provider side of that protocol.
What an MCP server exposes
An MCP server exposes three kinds of things to clients. Tools are actions the AI can invoke, such as querying a database, calling an API, or performing a computation, the verbs the server offers. Resources are data the AI can read, such as files or records, the nouns. Prompts are reusable templates the server provides to guide the AI in using its capabilities. Together these let a server offer functionality, data, and guidance through one interface.
Of these, tools are usually the focus, because they are what let an agent do things. An MCP server for a database might expose tools to query and update it; one for a service might expose tools to call its operations. The client discovers these tools, learns their inputs from the server, and calls them as needed. So when people talk about what an MCP server provides, they usually mean its tools, with resources and prompts as supporting capabilities, and tools are also what a paid MCP server typically charges for.
How agents use it
An AI agent uses an MCP server by acting as an MCP client. It connects to the server, asks what tools and resources are available, that discovery step is part of the protocol, and then calls the tools it needs as it works. Because the protocol is standard, the agent does not need a custom integration for each server; it speaks MCP, and any MCP server is reachable the same way.
This is what makes MCP servers valuable for agents: they extend what an agent can do without bespoke wiring. An agent that speaks MCP can use any MCP server it is given access to, composing capabilities from many servers. The discovery step matters here, since it is how the agent learns what a server offers before using it, and it is also why a paid MCP server keeps discovery free, so a calling agent can see the tools before paying for them. The standard client-server interaction is what lets agents draw on a growing ecosystem of MCP servers.
Transports
An MCP server communicates over a transport, and the two common ones are stdio and Streamable HTTP. With stdio, the server runs as a local subprocess and communicates over standard input and output, which suits local, single-user use on the same machine as the client. With Streamable HTTP, the server is reached over HTTP, which suits networked use where clients connect remotely.
The transport choice is usually about deployment, but it becomes decisive for payments. The x402 adapter gates an HTTP route, and a stdio server has no HTTP route to gate, so a stdio MCP server cannot be charged for as it stands. A paid MCP server must therefore use the Streamable HTTP transport, which exposes the endpoint the adapter sits in front of. So while transport is often a deployment detail, for anyone planning to monetize an MCP server it is the first decision, since it determines whether the server can be gated at all.
Monetizing an MCP server
Because an MCP server provides valuable capabilities, it can be monetized, and the common way is to gate its HTTP endpoint with x402. You front the server's route, served over Streamable HTTP, with the x402 adapter, so an unpaid call gets a 402 quoting a price and a paid one settles in USDC on Base before the tool runs. Pricing is per route, so you charge for tools by arranging them across routes, while keeping discovery free so callers can see what is offered.
This turns an MCP server into a paid service that any capable agent can use without a signup, which fits the agent ecosystem the protocol serves. The architecture of a payment-enabled MCP server, the transport requirement, the gate in front, the free discovery route, is covered in mcp-payment-server, and the step-by-step build in how-to-build-a-paid-mcp-server. The point for the definition is that an MCP server is not only a way to give agents capabilities but, when served over HTTP and gated, a way to sell them.
A concrete example
A simple example grounds the idea. Suppose you run a specialized search service over a proprietary dataset. You wrap it in an MCP server that exposes one tool, search, taking a query and returning results. An agent given access connects to your server, discovers the search tool and its inputs, and calls it whenever its task needs that dataset, getting results back in the standard MCP format.
If you serve that server over Streamable HTTP and front the route with the x402 adapter, the same search tool becomes a paid capability: an agent that has never contacted you before calls it, gets a 402, pays a few cents in USDC, and receives results, with no account created. That single example, a useful tool exposed over MCP and optionally gated for payment, is the whole arc of what an MCP server is and what it can become, from a way to give agents a capability to a way to sell one.
Related terms
An MCP server connects to several concepts. A paid MCP tool is a tool on an MCP server that callers pay to use. The x402 protocol is how a paid MCP server charges. The Streamable HTTP transport is what makes gating possible. An MCP client is what connects to the server, often an AI agent. And agentic commerce is the broader setting where paid MCP servers fit.
Understanding the MCP server is the foundation for the paid-MCP topics, since it is the thing being monetized. For the architecture of charging for one, see mcp-payment-server; for the build, see how-to-build-a-paid-mcp-server. Pricing is on the pricing page.