Creating MCP Servers — Local or Remote
Asha keeps her tickets and itineraries as PDFs in a folder on her laptop. Tripmate's railway timetable, on the other hand, lives on the railway company's servers and is used by thousands of people. Both can be offered as MCP servers, but they are built and run very differently. The first question when creating a server is where it should run.
The rule
Local servers live beside the user; remote servers live on the network and must authenticate.
A local server runs on the user's own machine. The host usually starts it as a child process and talks to it through standard input and output — no network port at all. It suits anything tied to that machine: local files, a local database, desktop apps. It runs with the user's own permissions, and it only serves that one user.
A remote server runs as a web service. Hosts connect to it over HTTP from anywhere. It suits shared services — a timetable, a company knowledge base, a payments system. Because anyone on the network could try to connect, it needs authentication (commonly an OAuth sign-in flow), per-user permissions, rate limits and the usual care of running a web service.
A host's configuration for a local server often looks something like this — a command to launch it:
{
"servers": {
"trip-files": { "command": "python", "args": ["trip_files_server.py", "--folder", "~/Trips"] }
}
}A remote server is instead registered by its URL, and the user signs in when the host first connects.
Whichever you choose, the building steps are the same:
- Choose the capabilities — which tools, resources and prompts.
- Define each tool — name, description and input schema, exactly as in any tool definition.
- Write the handlers — the code that runs when a tool is called.
- Pick the transport — standard input/output for local, HTTP for remote.
- Test with a client before connecting a real host.
The shortcut
Ask two questions: "Whose data is it?" and "How many people use it?" One person's machine → local. Shared data or many users → remote, with authentication from day one.
Trip files
Asha's PDFs, on her laptop, used only by her. Local server, launched by the host, limited to
~/Trips.
The trap is shipping a remote server with no authentication "just for now". A server on the network with tools that act on accounts is open to anyone who finds its address.
Drills
Answer fast — trust the rule.
How does a host usually talk to a local MCP server?
A company wants all employees' AI apps to search its shared wiki. Which fits best?
What must a remote server have that a local one often does not?
Which step comes first when creating an MCP server?
Remember
- Local servers run beside the user over standard input and output; remote servers run on the network over HTTP.
- Shortcut: whose data, and how many users? One machine → local; shared → remote.
- Trap: a remote server without authentication.