An MCP server is how your product, your data, or your own scripts become something an AI agent can use on its own. Build one, and Claude, ChatGPT, Cursor, or any other MCP client can read from your tool and act in it when a founder asks.

The good news: a first MCP server is a small project. The official SDKs handle the protocol, so most of your work is deciding what your agent should be able to do and describing it well. This guide walks through the whole path: the tools, the code, testing, hosting, sign-in, and getting your server in front of the founders and agents who need it.

You don't need a team for any of it. You need one clear job for your server and an afternoon to start.

What is an MCP server, and what does it do?

An MCP server is the tool's side of the Model Context Protocol. It tells an AI app what it can do, takes requests in a shared format, and sends results back. If you're new to the idea, start with What is MCP?, then come back here.

An MCP server can offer three kinds of capabilities:

  • Tools: functions the model can call, like "search orders" or "create invoice". The model calls them, usually with your approval.
  • Resources: file-like data the client can read, like an API response or a document.
  • Prompts: ready-made templates that help someone finish a specific task.

Most first servers are mostly tools, and so is this guide.

What do you need before you build an MCP server?

Building an MCP server takes three things: a job, a language, and a client to test with.

  1. One job. Write one sentence about what an agent should be able to do with your server. "Look up a customer's orders and refund one" is a job. "Everything our API does" is not.
  2. A language with an official SDK. The MCP project rates its SDKs in tiers. TypeScript, Python, C#, Go, Rust, and Ruby are Tier 1. Java is Tier 2. Swift, PHP, and Kotlin are Tier 3. Pick the one you already ship in.
  3. A runtime. The official Python tutorial needs Python 3.10 or newer and version 2.0.0 or newer of the Python SDK. The TypeScript tutorial needs Node.js 20 or newer.
  4. A client to test in. Claude for Desktop, Claude Code, and Cursor all connect to MCP servers, and the MCP Inspector lets you test without any AI app at all.

A coding agent speeds this up a lot. Claude Code and Cursor can read the official docs with you and write the first version of your server while you decide what it should do.

How do you design the tools your MCP server offers?

Good MCP tools come from the agent's point of view, not from your API's endpoints. Anthropic's engineering team calls tools that only wrap existing API endpoints a common mistake, and recommends a few thoughtful tools built around real workflows.

Use these rules when you name and shape each tool:

  • Build fewer, bigger tools. One tool that finds a customer and returns their recent orders beats three tools the agent has to chain together.
  • Name tools so they group. A shared prefix, like orders_search and orders_refund, helps an agent tell related tools apart from other servers' tools.
  • Write the description like a prompt. The description goes into the agent's context, and Anthropic reports that small changes to descriptions can make large differences in how well agents use a tool.
  • Return what matters. Send back names, totals, and status, and leave out internal ids the agent can't use.
  • Keep responses short. Add filters, pagination, or a sensible default limit. Claude Code limits tool responses to 25,000 tokens by default.
  • Make errors useful. An error that says what to change lets the agent fix its own request.

Mark what each tool does to the world. The MCP spec defines hints such as readOnlyHint and destructiveHint, so a client can tell a lookup from a delete. Clients treat these hints as untrusted unless your server is one they trust, so they help the person approving a call, but they never replace your own checks.

How do you build an MCP server, step by step?

The official MCP tutorial builds a small weather server with two tools in Python, TypeScript, Java, Kotlin, C#, Ruby, Rust, and Go. Every version follows the same steps:

  1. Create the project. In Python, the tutorial uses uv to start a project and add the mcp[cli] package. In TypeScript, it installs the @modelcontextprotocol/server package.
  2. Create the server. You give it a name. In Python, the MCPServer class reads your type hints and docstrings to build each tool's definition for you.
  3. Register your tools. Each tool gets a name, a description, an input schema, and a function that does the work.
  4. Pick a transport. For a server that runs on your own machine, that's stdio. For one on the internet, it's Streamable HTTP.
  5. Log to stderr, never stdout. A stdio server talks to the client over standard output, so a stray print statement corrupts the messages and breaks the server. Use a logger that writes to stderr.
  6. Run it. Start the server, and it waits for a client to connect.

The tutorial's finished code lives in the official quickstart-resources repository, so you can start from a working server and change it into yours.

How do you test an MCP server before anyone uses it?

The MCP Inspector is the official tool for testing MCP servers, and it needs no AI model. Run npx @modelcontextprotocol/inspector with the command that starts your server, and it opens in your browser. The same package also has a command-line mode for scripts and CI, and a terminal mode. The Inspector needs Node 22.19.0 or newer.

Test in this order:

  1. List the tools. Check that every tool shows up with the name and description you wrote.
  2. Call each tool. Try good inputs, missing inputs, and wrong inputs, and read the errors the way an agent would.
  3. Check both protocol eras. The Inspector starts in its legacy mode. Run your test once more with the modern era, so your server answers both older and newer clients.
  4. Connect a real client. For Claude for Desktop, add your server under mcpServers in claude_desktop_config.json, use the absolute path to your server, and restart the app.
  5. Read the logs when it fails. On a Mac, Claude for Desktop writes MCP logs to the Logs/Claude folder in your Library, and mcp.log shows connection failures.

Should your MCP server run locally or remotely?

A local MCP server runs on the user's machine over stdio. A remote MCP server runs on the internet over Streamable HTTP, where every message is an HTTP POST to one endpoint. The older HTTP+SSE transport is deprecated, so new servers should use Streamable HTTP.

Choose local when your server works with files or apps on one person's computer. Choose remote when founders should connect by pasting a URL, with nothing to install.

Two hosts have official guides for remote MCP servers:

  • Cloudflare: Cloudflare's guide starts from a template for a public server without sign-in, built with the Agents SDK, and deploys it to a workers.dev address with Wrangler. When you need sign-in, Workers OAuth Provider adds it.
  • Vercel: Vercel's guide adds an MCP route to a Next.js app with the mcp-handler package. It runs on Vercel Functions with Fluid compute, which Vercel says handles the long idle times and quick bursts MCP traffic tends to have.

You'll find more hosting options on the backend and hosting page of the ZeroCrew directory.

How do you add authentication to an MCP server?

MCP authorization is optional, and the official docs strongly recommend it when your server touches user data, takes actions people must consent to, or needs per-user limits. A local stdio server can read credentials from environment variables. A remote server uses OAuth 2.1.

The remote flow works like this:

  1. A client calls your server without a token, and your server answers 401 with a link to its protected resource metadata.
  2. The client reads that metadata to find your authorization server and its scopes.
  3. The client registers, the person signs in and approves, and the client comes back with a token issued for your server.

Three rules keep your users safe:

  • Accept only tokens issued for your server. The spec forbids token passthrough, where a server forwards a token meant for some other service.
  • Ask for the smallest scopes. Broad scopes widen the damage if a token leaks, and long consent screens make people say no.
  • Keep a human in the loop. The MCP spec says a person should always be able to deny a tool call, so make write actions easy to review.

Libraries do most of this for you. Cloudflare's Workers OAuth Provider can run the authorization server. Vercel's mcp-handler verifies tokens and publishes the metadata, and you bring the authorization server.

What changed for MCP server builders in 2026?

The MCP specification released on July 28, 2026 made the protocol stateless. It removed the opening handshake and protocol-level sessions, so every request carries its own protocol version and client capabilities. Servers now answer a new server/discover request that lists their versions, capabilities, and identity.

For you, this mostly means staying on a current SDK. The official TypeScript tutorial shows a server that answers both new clients and clients that still use the older handshake, which is why testing both eras in the Inspector matters. A stateless server is also simpler to host, because any request can land on any server instance behind a plain load balancer.

How do founders find your MCP server once it's live?

A live MCP server reaches founders when it's listed where they and their agents look. Two places matter most.

The official MCP Registry. The registry stores metadata about public MCP servers, not their code, and it's in preview today. You describe your server in a server.json file, sign in with the mcp-publisher command-line tool, and publish. Signing in with GitHub gives you a name under your GitHub account. Proving you own a domain lets you use the domain as your name.

ZeroCrew. Once your tool is in the ZeroCrew directory, your server can reach founders building companies with zero employees:

  • The MCP servers list. Every tool in the directory with its own MCP server appears on the MCP servers list, grouped by role, so a founder looking for sales or finance tools sees yours there.
  • A launch. ZeroCrew Operators launch tools on the Launchpad and in the Monday email to members, and Operators who use your tool can review it on its page.
  • Agent discovery. ZeroCrew's own public MCP server lets any agent search the directory with no sign-in, so when a founder asks their agent which tool fits a job, the agent can find yours.

That public server is also a working example to learn from. Add https://zerocrew.ai/api/mcp/public to your MCP client or the Inspector. It has four tools: search_tools, get_tool, list_roles, and list_job. Each one has a plain, specific description, and each is marked read-only. It's a small server that does one job well, which is the best shape for your first one.

An Operator seat is won in ZeroCrew's Friday auction, starting at $10 a year as of October 2026. See pricing for how it works.

Start with one job, three tools, and the Inspector. Ship it, list it, and let agents put it to work.