How to build an MCP server, and what MCP is used for

To build an MCP server, pick an official SDK (TypeScript or Python), define the tools, resources or prompts you want an AI model to use, choose a transport (stdio for local use, Streamable HTTP for remote), test it with the MCP Inspector, then add it to a client such as Claude, Cursor or ChatGPT. MCP gives AI agents a standard way to reach outside data and actions.

Transport	Where it runs	Auth	Good for
stdio	Launched by the client on the same machine	Environment variables, local secrets	Personal tools, prototypes, local files
Streamable HTTP	Hosted at a URL	OAuth or bearer key	Shared or public servers, nothing for users to install

What MCP is used for

MCP (Model Context Protocol) is an open standard, introduced by Anthropic in late 2024, for connecting AI applications to outside tools and data. Before it, each assistant needed its own custom integration for every service. With MCP you write a server once and any compatible client can use it.

Common uses:

Reading internal data: a database, a docs folder, a ticket queue or a data warehouse.
Taking actions: creating a CRM record, opening a pull request, posting to Slack.
Wrapping a third-party API so an agent can call it from a plain-language request, for example payments, analytics or B2B contact data.
Sharing one integration across Claude, ChatGPT, Cursor and other clients instead of maintaining one per app.

For a fuller definition, see what is an MCP server.

How an MCP server works

There are three roles. The host is the AI app the user works in. The client is the connection the host opens to each server. The server is your program. They exchange JSON-RPC 2.0 messages.

A server can expose three kinds of things:

Tools: functions the model can call, each with a name, a description and a JSON Schema for its inputs.
Resources: read-only data the client can load as context, addressed by URI.
Prompts: reusable templates a user can pick from a menu.

Most servers start with tools only. The model reads the tool names and descriptions, decides which to call and with what arguments, and the client forwards the call to your server and hands the result back to the model.

How to build an MCP server, step by step

Decide the job. Write down the 3 to 10 actions an agent should be able to take. Fewer, clearer tools beat one tool per API endpoint.
Pick an SDK. The official TypeScript and Python SDKs handle the protocol, so you only write tool logic. Install the Python one with pip install "mcp[cli]".
Define your tools. In Python, type hints and the docstring become the tool schema and description:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("northwind-crm")

@mcp.tool()
def list_stale_deals(min_amount: int, days_idle: int = 14) -> list[dict]:
    """Open deals above min_amount with no activity for days_idle days."""
    return query_warehouse(min_amount, days_idle)  # your own code

if __name__ == "__main__":
    mcp.run()  # stdio by default

Test it. Run mcp dev server.py to open the MCP Inspector, list the tools and call them by hand before any model touches them.
Connect a client. In Claude Code, claude mcp add northwind -- python server.py registers a local server. Desktop apps and Cursor take a similar entry in their MCP settings.
Ship it. To share it, run it over Streamable HTTP (mcp.run(transport="streamable-http")), host it, and add authentication. The MCP spec uses OAuth for remote servers.

Local or remote: choosing a transport

With stdio, the client starts your server as a subprocess on the user's machine. It is the quickest way to start, and secrets stay in local environment variables, but every user has to install and run it.

With Streamable HTTP, the server lives at a URL and many users connect to it. You take on hosting, auth and rate limits, and users install nothing. Leadsets is an example: it runs as a remote server at https://mcp.leadsets.ai, and Claude users add it as a custom connector and sign in with OAuth, with no key to paste (setup guide).

Designing tools agents use well

The protocol is the easy part. What decides whether an agent uses your server well is tool design:

One job per tool, named plainly. search_people and verify_email are easier for a model to choose between than one do_request tool.
Treat descriptions as prompts. Say what the tool does, when to use it and what the inputs mean.
Return structured data with context. Include why a result matched and how fresh it is, so the model can judge it. Leadsets returns match reasons, verification status and a checked date on each record.
Make errors machine-readable. A type and a retry time let the agent recover on its own. Leadsets returns a 429 with a Retry-After header and an error type such as window_full (error reference).
Let the agent check its budget. A free usage tool, like Leadsets' get_usage, helps an agent plan a large run instead of failing halfway.
Paginate and cap results so one call cannot flood the context window, and use idempotency keys on anything that writes or costs money.

Example: one server built, one connected

Maya Chen runs revenue operations at Northwind Analytics (northwind.co). She wants Claude to answer "Which open deals over $50k have gone quiet for two weeks?" That data lives only in Northwind's warehouse, so she builds a small stdio server with two tools, list_stale_deals and get_account_notes, in about 80 lines of Python.

She also wants Claude to find new prospects with verified work emails. Building that server would mean licensing data, verifying addresses and refreshing records, which is a data business rather than an integration. So she connects an existing remote B2B data server instead and spends her time on the internal one.

When you do not need to build one

Build a server when the data is internal or no server exists for the service you need. If a vendor already publishes an MCP server, connecting it is usually faster and keeps maintenance with the vendor. MCP also pairs with skills, which teach an agent a workflow rather than giving it a new tool; see what are Claude skills. If the gap is prospect and company data, compare options in B2B data APIs for AI agents or see how Leadsets works with agents.

Questions and answers

What is MCP used for?

MCP is used to connect AI assistants and agents to outside data and actions through one standard protocol. Typical uses are reading internal databases or documents, taking actions in tools like a CRM or Slack, and wrapping third-party APIs so an agent can call them from a plain-language request.

What language should I use to build an MCP server?

Use whichever language your team already works in that has an official SDK; TypeScript and Python are the most common starting points. The SDK handles the JSON-RPC protocol and schemas, so your code only needs to implement the tools.

What is the difference between a local and a remote MCP server?

A local server runs on the user's machine over stdio, launched by the client as a subprocess. A remote server is hosted at a URL over Streamable HTTP, so many users can connect without installing anything, but you have to handle hosting and authentication such as OAuth.

How do I test an MCP server?

Use the MCP Inspector, which connects to your server, lists its tools, resources and prompts, and lets you call them by hand. With the Python SDK, running mcp dev server.py opens it directly. Test each tool there before connecting a real model.

Is an MCP server the same as an API?

No. An API is a set of endpoints for any program to call, while an MCP server describes tools in a way an AI model can discover and choose between. Many MCP servers are thin layers over an existing REST API, adding tool descriptions, schemas and agent-friendly errors.

Do MCP servers work with ChatGPT and Cursor as well as Claude?

Yes, MCP is supported by many clients, including Claude, Claude Code, ChatGPT and Cursor, which is the main reason to build on it. A remote server can usually be added to any of them by URL, while a local server is registered as a command to run.

Go deeper