How to Build an MCP Server (Production-Safe)

Here is the thing nobody tells you before you build your first MCP server: the tool is the easy part. You will write the actual function, the thing that queries your database or sends the message, in about twenty minutes. Then you will spend three days on authentication, input validation, and making sure your server cannot be turned into a data-exfiltration device. That ratio is the whole story, so let us spend our time where the work actually is.

The shape, fast

MCP has three roles: a host (the AI app), a client inside it, and the server you build. Your server exposes three kinds of things over JSON-RPC:

• Tools the model can call (an action, with a name, a description, and an input schema).
• Resources it can read (URI-addressable context).
• Prompts a user can invoke (templates, often surfaced as slash commands).

For a fuller tour of the protocol itself, see what MCP is. Here we are building.

A minimal server

In TypeScript, using the official SDK's McpServer, a working tool is genuinely this small:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "weather", version: "1.0.0" });

server.registerTool(
  "get_forecast",
  {
    description: "Get the forecast for a city.",
    inputSchema: { city: z.string() },
  },
  async ({ city }) => ({
    content: [{ type: "text", text: `Sunny in ${city}.` }],
  })
);

await server.connect(new StdioServerTransport());

Python is just as compact with the high-level FastMCP API, where your type hints become the schema and the docstring becomes the description. One note on versions: as of mid-2026 the stable, production line is the v1 SDKs, targeting the 2025-11-25 spec. Newer major versions exist but are still beta, so do not build production on them yet, and verify class names against the live docs before you copy anything.

That z.string() is not decoration. Validating every argument against a schema is your first and cheapest line of defense.

Local or remote: pick your transport

There are two transports, and the choice shapes everything downstream.

• stdio is for local servers. The host launches your server as a subprocess and talks over standard input and output. Credentials come from environment variables. There is no OAuth here at all, so builders who bolt authentication onto a local server are usually solving a problem they do not have. The real local risk is command execution, so sandbox what you spawn.
• Streamable HTTP is for remote servers behind a URL. It replaced the older two-endpoint HTTP-plus-SSE design, which is now deprecated, with a single endpoint that is far friendlier to load balancers.

One high-leverage detail: sessions are optional. If your server keeps no session state, every request is self-contained, which means it scales trivially on serverless and behind an ordinary load balancer with no sticky routing. Reach for stateful sessions only when you truly need the server to push streams, not by default.

The part that is actually hard: auth

For remote servers, your server is an OAuth 2.1 resource server, and the authorization server is a separate role (your own, or Auth0, Okta, Entra). The spec's 2025 revision made that separation explicit, and it hands your server a short list of non-negotiables:

• Advertise your protected-resource metadata, and answer an unauthenticated request with a 401 that tells the client where to authenticate.
• Clients use PKCE and request a token bound to your server's audience.
• Your server must validate that every token was issued specifically for it, and reject anything else.
• If your server calls an upstream API, it gets its own token. Never pass the client's token through. Token passthrough is the single most common footgun, and the spec forbids it outright.

If that feels like more work than the tool, good, you are paying attention. Most of the MUST-level burden in the spec is auth and validation, not tool logic.

The security bit that surprises everyone

Beyond that, the production checklist is boring and essential: validate every tool argument against its schema, give each tool the least privilege it needs (a tool that cannot delete cannot be tricked into deleting), validate the Origin header on HTTP connections to block DNS-rebinding, and do not trust tool output either, since it can carry injected content back into the model. The same least-privilege discipline runs through all of AI agent security.

Test it, then ship it

Before you connect a server to a real model, run it through the official MCP Inspector, which gives you a UI and a CLI to list and call tools directly. It has a scriptable mode, so you can put tools/list and a few tool calls into CI and catch a broken schema before a model does.

For deployment, local servers ship as a binary the host spawns; remote servers run as a hosted service, and several platforms now offer one-click remote MCP hosting with OAuth handled for you. Those offerings move fast, so check the current feature set before you commit to one.

The takeaway

Building an MCP server is a study in where the real cost lives. The tool is trivial. The value, and the risk, is in the auth you get right, the inputs you validate, and the descriptions you treat as hostile. Get those three right and you have a server you can actually put in front of a model in production.

This is exactly the work we do when we build MCP integrations: the connector is the easy part, and the auth, scoping, and validation are the job. If you are exposing your systems to AI, let us make sure it is done safely.

References

• Model Context Protocol specification: the current spec, including transports and authorization.
• MCP security best practices: token passthrough, confused deputy, and session hygiene.
• Invariant Labs: MCP tool poisoning: hidden instructions in tool descriptions.