We build a cloud whose agents operate it over MCP, so we spend a lot of the week talking to servers we wrote. Every one of those servers is hosted, always-on, and billed by the hour. But before any tool of ours is hosted, it lives on a laptop, behind a tunnel, answering calls from an agent on the same desk. That stage is free, it is where everyone should start, and this post is about how much you can get done there before you pay anything.
The short version for anyone searching this exact question: yes, you can host an MCP server for free. Run it on a machine you already own, use the free tier of a managed platform, or use serverless if your tools keep no state. Each is genuinely free and each breaks in a way you can predict. We have hit all three breaks, from both sides: as the people hosting the tools, and as the platform that inherits them when they grow.
| Path | What it costs | Where it breaks | Who it suits |
|---|---|---|---|
| Your machine behind a tunnel | $0 | The machine sleeps, reboots, loses wifi; the tool is up only while you are | Development and solo experiments |
| The free tier of a managed platform | $0, the platform carries the idle hours | One instance, a memory ceiling, sometimes a request cap | A first real tool, before a teammate depends on it |
| Serverless, stateless tools only | $0 per call and response | No state and no held connections; most MCP servers do not qualify | Pure call-and-return tools |
The rest of this post is about where each of those breaks, because that is the part the table cannot tell you.
The tunnel stage, and why it ends
Your laptop can be an MCP server tonight. Start the process, put a tunnel in front of it, point your agent at the URL, and you have a hosted server for zero dollars. We still develop this way; nothing beats editing a tool and watching the agent pick up the change seconds later.
It ends the first time the tool is useful to someone who is not you. A tunnel only works while the machine is awake, and the machine is yours: it sleeps when you sleep, it reboots when an update lands, it loses the wifi exactly once, at the worst moment. A remote MCP server is only remote if it stays up. The lesson is not that tunnels are bad. It is that shared usefulness and shared uptime are the same requirement, and a laptop cannot provide either.
Free tiers are real, read the edges
The managed path costs nothing on a free tier, and we want to defend free tiers for a moment, because we run one. A free tier that carries one small always-on service costs the platform almost nothing and makes the platform useful enough that you stay. That is the whole trade, and it is a fair one.
What the edges look like, from our side of the fence: one instance, a memory ceiling, sometimes a request cap. One small MCP server is a lightweight process speaking HTTP, and it fits. What does not fit is the day two agents call at once, or the day your tool needs a database next to it and you start gluing vendors together for state that should live on the same platform.
If your tools keep no state at all, a serverless function is another zero-dollar route, and for a pure request-and-response tool it is a good one. Most MCP servers do not qualify: they hold connections open and remember things between calls, which fights the request-and-forget model. We tried the stateless-only shape ourselves and kept running back to a real process.
The math that hides under "free"
An always-on service, however small, is 730 metered hours a month. It answers twice a day and meters around the clock. Free tiers pay that slice for you because it is the cheapest loyalty program ever invented, and honestly, it works.
We wrote before about what an always-on VM actually costs once it is billed by the hour, and the punchline was a customer spending 84% of a real bill on one VM that never slept. Scale-to-zero exists because of stories like that. Free tiers are the same instinct pointing the other direction: the platform carries the idle hours so your first tool costs nothing. Neither model is charity. Both are fine, as long as you know which side of the meter you are standing on.
The day to stop being free
It is not a resource threshold, it is a trust threshold. You will notice one of these three things: you check that the server is up before you check your email, because a teammate's agent depends on it now. A workflow treats its downtime as an incident. Or a second process appears because one instance became a queue.
Any one of those means the tool has outgrown the free stage, and the move is smaller than people fear. On Scalix Run the free-tier deploy and the paid deploy are the same command, same URL, one setting changed:
scalix-cloud run deploy --name mcp-server \
--image registry.scalix.world/my-org/mcp-server:v1 \
--port 8080 \
--min-instances 1
You change a plan, not an architecture, and the URL your agents already know does not move. That matters more than the price. Re-pointing every agent that trusts your server is the real cost of outgrowing a host.
Where we land
Start free, on the machine or the tier, and mean it: the free stage is where your tool earns the right to exist. Then let the trust signals, not the invoice, tell you when to move. Start on the free tier, and if you want to see client configs for MCP servers we host ourselves, they are public at scalixworld/scalix-cloud-mcp.
Top comments (0)