Two kinds of MCP server
A local MCP server runs on the user's machine — launched by Claude Desktop, Cursor, or another host application as a subprocess. It has access to local files and tools. Great for personal developer workflows, but invisible to the outside world.
A remote MCP server runs at a public URL. Any agent, anywhere, can connect over HTTPS. This is the model that matters for businesses.
The distinction is like running a script on your laptop vs. deploying a web service. Both useful, fundamentally different problems.
Why remote wins for businesses
Reach. A local server works for users who manually install it. A remote server works for every agent, for every user, automatically.
Freshness. Local servers serve whatever was bundled at install time. Remote servers serve your current content. Update your docs, every agent sees it immediately.
Zero friction. Users don't install, configure, or update anything. Agents discover your server through DNS records, registry listings, and well-known files.
How agents find remote servers
- DNS — a CNAME at
mcp.your-domainis the primary signal - Well-known files —
/.well-known/mcp.jsontells agents where your endpoint lives - Registries — public directories list available MCP servers
- Skills manifests —
/.well-known/agent-skills.jsondescribes capabilities
Getting started
One CNAME record. Five minutes. No code changes.