How to make an MCP server

The official build guide names three kinds of capability a server can offer. Resources are file-like data that clients can read, such as API responses or file contents. Tools are functions the model can call, with the user’s approval. Prompts are pre-written templates that help users with specific tasks. Most first servers expose tools, and the guide does the same.

Then choose the transport. The architecture page says local servers using stdio usually serve a single client, while remote servers using Streamable HTTP usually serve many. Over HTTP a server can accept bearer tokens, API keys or custom headers, and MCP recommends OAuth to obtain tokens. Start local unless other people need to reach the server.

The MCP documentation’s build guide makes a weather server with two tools, get_alerts and get_forecast, which call the US National Weather Service API, and connects it to Claude for Desktop. The Python track, as read on 7 October 2026, runs as follows.

The TypeScript track installs the @modelcontextprotocol/server package and zod and needs Node.js 20 or higher. The same guide has tabs for Java, Kotlin, C#, Ruby, Rust and Go, and the SDK page lists the official SDKs in the table on this page.

• Check the requirements: Python 3.10 or higher and the Python MCP SDK 2.0.0 or higher.
• Install the uv tool, create a project with uv init, create and activate a virtual environment, add the mcp package with its command-line extras, and create the server file.
• Create a server instance with the MCPServer class and give it a name. The guide says the class uses Python type hints and docstrings to generate the tool definitions.
• Write helper functions that call the upstream API with error handling, so a failed request returns a clear message instead of crashing the server.
• Mark each tool function with the tool decorator. The docstring becomes the description the model reads, and the typed arguments become the input schema.
• Run the server with the stdio transport, then start it with uv run to check that it launches.
• Add the server to claude_desktop_config.json under the mcpServers key, with the command and the absolute path to the project. You may need the full path to uv.
• Quit Claude for Desktop completely and start it again, because closing the window does not reload the configuration.

For servers on the stdio transport, the guide is blunt: never write to standard output, because doing so corrupts the JSON-RPC messages and breaks the server. In Python, keep print out of the server and use the standard logging module, which writes to standard error. In TypeScript, use console.error instead of console.log. Servers on HTTP can log to standard output safely.

Claude for Desktop writes its MCP logs to ~/Library/Logs/Claude on macOS and ~/.config/Claude/logs on Linux. The file mcp.log covers connections and connection failures, and a file named after each server holds that server’s standard error output.

In Claude for Desktop, open the add files and connectors menu and look for your server under Connectors. Then ask a question that should need a tool; the guide uses the weather in Sacramento and the active alerts in Texas. Claude reads the available tools, picks one, the client runs it through your server, and the result returns to Claude for the answer.

If the server does not appear, the guide says to check the configuration file syntax, make sure the project path is absolute, and fully restart the host. For deeper checks, the MCP project lists the MCP Inspector among its tools for developing servers and clients.

The MCP security best practices page lists attacks and the rules that prevent them. These apply to the server you write.

• Accept only tokens issued for your server. The guidance says MCP servers MUST NOT accept tokens that were not explicitly issued for them, and forbids passing a client’s token through to a downstream API.
• If your server proxies a third-party API with one static OAuth client ID, implement consent for each client before forwarding, to prevent confused deputy attacks.
• For a local server, prefer stdio so that only the MCP client can reach it. If you use HTTP locally, require an authorisation token or use a restricted IPC channel such as a unix domain socket.
• If a tool returns a handle to saved state, such as a cart or workflow ID, generate it randomly, bind it to the authenticated user, and never treat possession of the handle as authentication.
• Ask for the narrowest scopes that do the job and request more only when a privileged tool is first used. Avoid wildcard or catch-all scopes.
• For tools that change data, rely on the host’s approval dialog and keep the tool narrow, so that each approval means one clear action.

Agents built in Studio can act as MCP clients and call tools on external MCP servers, so a server you build and host can serve a Studio agent as well as a desktop host. Studio can also deploy MCP servers from templates into a workspace, and each deployment answers tools/list.

Calls through Swfte’s MCP gateway need an API key scoped to that server, and the gateway logs the workspace, server, method, status and latency. Per-tool allow and deny rules, call-level rate limits and recording of tool arguments are not built, so keep the security rules above inside your own server.

• MCP gateway: what Swfte checks and logs
• Swfte Studio: agents as MCP clients
• PostgreSQL MCP template

Facts about other vendors and about the terms on this page were read on the pages below on 7 October 2026. Vendor plans, names and menus change, so check the vendor’s page before you rely on a detail.