How to Deploy and Connect an MCP Server: A Step-by-Step Guide
An MCP server lets a language model move beyond the chat window and work with real tools: databases, files, external APIs, and monitoring systems. The phrase «deploy and connect an MCP server» comes up more and more in 2026, because the protocol has become a shared standard for Claude, ChatGPT, Cursor, and other assistants. In this guide we cover the topic from the ground up and step by step: what MCP is, how it works, how to connect a ready-made server in a couple of minutes, how to write your own, and how to host a remote server on a separate machine.
This material is written for a broad audience, so we explain the basics in plain language and give the technical steps as ready-to-run commands you can repeat. To set the scale: the MCP ecosystem already counts thousands of ready-made servers, and the protocol is often compared to a USB-C port, a single connector that links AI to the outside world.
What an MCP Server Is and Why You Need One
MCP stands for Model Context Protocol, an open protocol that defines a single way for a language model to talk to external tools and data. Anthropic introduced it in November 2024, and within about a year and a half it grew into a common standard. Today it is supported by Claude, ChatGPT, Cursor, VS Code with Copilot, and many other applications.
The core idea is simple. In the past, every integration meant separate code: one wrapper for a database, one for GitHub, one for an internal API. With the protocol the picture changes: we write a server once, and any compatible assistant can connect to it. That is where the USB-C comparison comes from, a single connector that fits many devices.
Three roles take part in the system, and it helps to tell them apart from the start.
- The AI application the user works through. Examples: Claude Desktop, Cursor, ChatGPT.
- The internal part of the host that holds a connection to one server. Each server gets its own client.
- The thing we deploy. It gives the assistant specific capabilities.
A server can expose three kinds of capabilities: tools (functions the model calls, such as «create a record» or «fetch a metric»), resources (data to read, such as the contents of a file), and prompts (ready-made templates for common tasks). In practice, tools are used most often.
The numbers show how mature the technology is. By May 2026, GitHub held around 16,000 repositories tagged mcp-server, and total SDK downloads run into the tens of millions per month. For a business, that means a large ecosystem has formed around the protocol, and ready-made solutions already cover most tasks.
How MCP Works: the stdio and Streamable HTTP Transports
Under the hood, all communication runs over the JSON-RPC format: the client sends a request, the server returns a response. The way these messages are delivered is called the transport, and the choice of transport decides where the server lives and who connects to it. There are two transports, and understanding the difference solves half the questions that come up during deployment.
stdio for Local Use
The stdio transport runs the server as a local subprocess right on the user computer. The host starts the program itself and talks to it through standard input and output streams. This option suits work on a single machine, development, and personal tools: latency is minimal and no separate infrastructure is required.
One detail trips up newcomers. In a stdio server you must never write anything to standard output (stdout), because that channel carries the protocol own messages. Any stray print or console.log breaks the exchange. We send all logs to the error stream (stderr) or to a file.
Streamable HTTP for Remote Access
The Streamable HTTP transport is meant for remote servers and several clients at once. Messages travel as ordinary HTTP requests to a single address, for example /mcp, and the server streams its reply when needed. This is the current specification standard for remote deployments, and it replaced the older standalone SSE transport. The big advantage is that Streamable HTTP plays well with familiar web infrastructure: load balancers, proxies, and gateways.
The protocol keeps evolving. A major specification update planned for summer 2026 makes the protocol core stateless, which means the server stops holding session state and scales more easily behind a plain load balancer. In practice, that makes remote servers simpler to run across several copies.
What You Need Before You Start
Before we deploy and connect an MCP server, we prepare the working environment. The set depends on the path you choose, so here is the minimum.
- For Python servers you need a Python interpreter and the uv package manager. For Node.js servers you need Node installed together with npm. Ready-made servers usually launch through npx (Node) or uvx (Python), so the matching runtime has to be present locally.
- A host with MCP support. Claude Desktop, Cursor, or another compatible assistant will do. We use it to confirm that the server is visible and the tools work.
- A machine for the remote path. If we plan to keep an MCP server reachable from outside, we need a separate machine with a public IP, a domain, and steady uptime. A virtual server fits this role.
- Basic terminal skills. Most steps come down to a few commands in the command line, and they do not require deep programming knowledge.
Once the environment is ready, we move on to practice. Next we walk through three methods, from the simplest to the most thorough.
Method 1. Connect a Ready-Made MCP Server in a Couple of Minutes
The fastest way in needs no coding at all. For popular tasks, ready-made servers already exist: file system access, GitHub, databases, search. We take a ready-made server and connect it to the host.
If we work through Claude Code, adding a server takes a single command in the terminal. For example, the file server connects like this:
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/folderA server that needs a token is added together with an environment variable:
claude mcp add github -e GITHUB_TOKEN=your_token -- npx -y @modelcontextprotocol/server-githubThe command claude mcp list shows connected servers, and claude mcp remove takes one away.
Claude Desktop is set up a little differently. We open the configuration file claude_desktop_config.json and add the server to the mcpServers section, giving the launch command and an absolute path. After saving, it is important to fully restart the application: simply closing the window will not pick up the changes. On macOS that is Cmd+Q, on Windows you quit from the tray icon.
A nice detail: the configuration format is almost identical across hosts. A server set up for Claude Desktop connects the same way in Cursor, Claude Code, and Windsurf. Set it up once, use it everywhere.
To confirm everything worked, open the connectors menu in the host. The server should appear in the list, and its tools should become available to the assistant. From there a plain text request is enough, and the model decides which tool to call.
Method 2. Write and Run Your Own MCP Server Locally
When no ready-made solution fits the task, we write our own server. It is easier than it looks: a working prototype comes together in about an hour. We walk the Python path with the FastMCP library, following the official scenario.
First we create the project and install dependencies:
uv init weather
cd weather
uv venv
uv add "mcp[cli]" httpx
Next we describe the server itself. We create a FastMCP object and register a tool through a decorator. FastMCP builds the tool description from type hints and the docstring, so there is no need to write a separate schema:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather")
@mcp.tool()
async def get_forecast(city: str) -> str:
"""Returns the weather forecast for a city."""
return f"Forecast for {city}"
We run the server on the stdio transport:
if __name__ == "__main__":
mcp.run(transport="stdio")
Here we recall the logging rule again. In a stdio server any output to the standard stream breaks the protocol, so debug messages go to stderr. In Python the safe option is print("text", file=sys.stderr) or the regular logging module.
Before connecting to a host it helps to test the server on its own. The official MCP Inspector tool does this: it launches with npx @modelcontextprotocol/inspector and shows the list of tools and their results without involving the model. If the tools are visible and respond, the server is ready, and you can add it to the host configuration the same way as in the first method.
Method 3. Deploy an MCP Server Remotely on a VPS
A local server lives on one machine and is reachable only by its owner. As soon as a team uses the server, or you need to connect it to the web version of an assistant, we move to remote deployment over Streamable HTTP. This calls for a separate machine reachable from the internet, and usually that is a virtual server.
The production setup looks like this. The client connects over the secure HTTPS protocol on port 443. Nginx sits on the server, terminates TLS, and acts as a reverse proxy. The MCP server itself listens only on a local address, for example localhost:3000, and is never exposed directly. This layout improves security and simplifies certificate handling.
The key point is a correct Nginx configuration, because MCP connections can be long. A minimal set of parameters for the block that serves /mcp looks like this:
location /mcp {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 300s;
}
What matters here. We raise the read timeout to at least 300 seconds, because the default 60 seconds cut long-running tools off mid-call. We set the protocol version to 1.1 and clear the Connection header, otherwise streaming breaks. The X-Forwarded headers help the server learn the real client IP and protocol, which is useful for logging and authorization. TLS certificates are easy to obtain for free through Let's Encrypt and the Certbot utility, leaving their issuance and renewal to Nginx.
We will name the downside of this path honestly. Remote deployment gives full control, while the care of certificates, proxy configuration, and keeping the process alive falls on us. So the server survives a reboot, it is set up as a system service through systemd or run inside a container.
A remote server needs a stable platform with a public IP, a fixed domain, and predictable performance. Serverspace VPS hosting fits this role: such a machine runs the Nginx and MCP server bundle, with resources allocated to the load of a specific project. A US-based data center and pay-as-you-go billing in ten-minute increments are convenient when the server is needed for a test or a short-lived task.
How to Connect a Remote Server to Claude, ChatGPT, and Cursor
Once the remote server is up and reachable over HTTPS, the last step is connecting it to the assistant. In most hosts this happens through a custom connector.
In Claude the path is: the Settings section, then Connectors, then adding a custom connector by the server address. In ChatGPT custom connectors are added through developer mode or workspace settings. Cursor tries the Streamable HTTP transport on its own when connecting by URL, so there is no need to specify it separately.
Authorization deserves separate attention. If the server is protected, the specification requires the OAuth 2.1 protocol. In practice that means the mandatory PKCE mechanism with the S256 method, an exact match of redirect addresses, and dropping outdated schemes. Public servers without sensitive data work without authorization, while anything that touches private systems must be protected.
If the host reports that it could not connect, the cause is usually the server address or the authorization setup. We collected the common failures in the next section.
Common Deployment Errors and How to Avoid Them
Most problems that come up when you try to deploy and connect an MCP server repeat from project to project. The table below is laid out as «symptom, cause, fix» and covers the most frequent situations. Keep it close while you configure.
| Symptom | Cause | Fix |
|---|---|---|
| Nginx returns a 502 Bad Gateway error | The MCP server is not running or listens on a different port | Check that the process is up and that the port in proxy_pass matches the server port |
| The connection drops in the middle of a tool call | The default proxy timeout of 60 seconds | Raise proxy_read_timeout to 300 seconds or more and enable HTTP/1.1 |
| The host reports «could not connect to the server» | The server is unreachable from outside, the address path is wrong, or the server only supports stdio | Check availability over HTTPS, confirm the address with /mcp, use Streamable HTTP for remote access |
| OAuth authorization fails | A redirect from the non-www domain to the www domain strips headers | Use the address in the form the redirect leads to and verify the OAuth endpoints |
| Server logs disappear and behavior is unpredictable | Output goes to stdout and breaks the protocol | Redirect all logs to stderr or to a file |
| The server is visible but tools are never called | A vague tool description, so the model does not know when to use it | Give a clear name and description and refine the input parameter types |
A word on prevention. Before connecting to a host, we always test the server with a separate tool such as MCP Inspector: that cuts out half the errors before the network and authorization come into play. If the server is remote, we first make sure it is genuinely reachable from the internet at the right address, and only then look deeper for the problem.
MCP Server Security: What to Check Before Launch
An MCP server gains access to data and tools, so we treat security seriously from day one. Here is a baseline set of rules that closes the main risks.
- Secrets only through environment variables. Tokens, passwords, and API keys must never be hardwired into the code or configuration. They live in environment variables or a secrets manager.
- Keep sensitive servers local. If a server works with private data, it is safer to run it on the stdio transport on your own machine, with no exposure to the internet.
- Minimal privileges. We grant keys and tokens only the access a tool actually needs. Extra privileges raise the cost of a mistake.
- Code review. Before connecting someone else server to working systems, it is worth reading its code. A malicious server can swap tool descriptions even after the user has approved them.
- Untrusted input. We treat data arriving in a tool as untrusted, because the model produces it. Strict validation of input parameters against a schema helps.
- It is handy to run the server in a separate container or environment to limit the fallout of a possible failure.
Data storage is a separate question. If a project carries data residency or compliance requirements (for example SOC 2 or HIPAA) and the information cannot leave US-based infrastructure, the server stays inside your own perimeter. Serverspace cloud servers in the USA help in that scenario: data stays under the owner control in a US data center, while the server remains reachable over the network for the hosts that need it.
Conclusion: Where to Start Right Now
We covered the path from the concept of MCP to remote deployment. Here is the short version.
- Beginners are best served by Method 1: take a ready-made server and connect it to Claude Desktop or Cursor in a couple of minutes.
- Developers will want Method 2: write their own server on stdio, test it in MCP Inspector, and register it with a host.
- Teams or production need Method 3: a remote server over Streamable HTTP behind Nginx with TLS, placed on a separate machine.
From there, move from simple to advanced. First connect one ready-made server and get a feel for how the assistant works with real tools. Then build your own for a specific task. When shared access becomes the goal, move the server to a remote platform: for production it is convenient to keep it on your own VPS, where resources and access are tuned to the project.
FAQ
How is an MCP server different from a regular API?
A regular API is an interface for programs and developers, where every request is known in advance. MCP describes how an assistant discovers the available tools on its own and picks the right one during a conversation. In essence, MCP wraps existing APIs so a model can use them.
Will MCP replace REST APIs?
No. REST and GraphQL stay in place for communication between programs and for human users. MCP solves a separate task: it gives a language model access to tools. These approaches work side by side and complement each other.
Which ready-made MCP servers are the most popular?
Among the common solutions are servers for the file system, GitHub, PostgreSQL databases, messengers, and search. The catalog holds thousands of options, so a ready-made server for a popular service usually already exists.
Do I need a VPS if I only work locally?
For personal work on one machine the stdio transport is enough, and a separate server is not required. A VPS becomes useful when a team uses the server or it has to be connected to the web version of an assistant over the network.
Can one server connect to several hosts at once?
Yes. The same server works with different hosts, because the protocol is shared. The setup format is almost identical across Claude Desktop, Cursor, and Claude Code, so you configure the server once and connect it everywhere.
Can I run an MCP server without a VPS or cloud infrastructure?
Yes. You don’t need a VPS if you’re only using MCP locally. In that case the server runs on your own machine via the stdio transport, and the AI host (for example Claude Desktop or Cursor) starts it as a local process. This is enough for personal tools, experiments, and development workflows, and it requires no public IP or server setup.
