MCP Server Tutorial: Build and Host an MCP Server on Zo

If you’re searching for an MCP server tutorial, you’re probably trying to do a simple thing: make an AI client (Claude, an IDE, a chat app, an agent framework) talk to your tools and data in a standard way.

MCP (Model Context Protocol) is that standard. It’s a client/server protocol: the client is the AI app you use; the server is a process you run that exposes tools (and sometimes resources/prompts) the client can call. MCP is meant to be “USB‑C for AI integrations” — one protocol, many tools. ^1

This tutorial shows a practical, Zo-friendly deployment path:

Understand the two common MCP deployment styles (local vs remote)
Build a tiny MCP server you can actually host
Run it on your Zo Computer as a long‑running service
Connect to it from an MCP client

What you’ll build

A minimal MCP server that exposes one “tool” (a callable function) over MCP. You’ll run it on Zo, keep it always on, and point MCP clients at it.

Prerequisites

A Zo Computer server (any plan is fine)
Basic comfort editing a file and running commands

Step 0: Decide whether you need “local” or “remote” MCP

MCP servers are commonly run in two ways:

Local / STDIO: the AI client launches the server as a local subprocess and talks over stdin/stdout. This is common for desktop apps and IDEs.
Remote / HTTP: the MCP server runs on a server and the client connects over the network (the newer MCP specs describe “Streamable HTTP”, and older setups used HTTP+SSE). ^2

If your goal is “I want other devices/teammates to use this MCP server” or “I want it always on”, you want the remote style — which is exactly what Zo is good at.

Step 1: Create a new project folder

In your Zo workspace, create a folder for the MCP server:

mkdir -p /home/workspace/Projects/mcp-server
cd /home/workspace/Projects/mcp-server

Step 2: Implement a tiny MCP server

The MCP ecosystem is moving quickly, and there are multiple SDKs (and multiple versions of the spec). Rather than hard-coding a specific SDK and risking “copy/paste doesn’t run”, use the official MCP docs’ current “build a server” guide as your source of truth and pick the SDK you prefer (Node or Python). ^3

Minimal shape of an MCP server

Regardless of language, you’ll implement the same basic ideas:

Advertise tools (name, description, input schema)
Handle tool calls and return results
Expose a transport:
- STDIO for local
- Streamable HTTP for remote ^2

For example, a good “first tool” is something like hello (returns a string) or get_time (returns a timestamp).

Step 3: Run it as an always-on service on Zo

Once your MCP server can run locally, you want it to stay up.

On Zo, you generally have two clean options:

Run it as a hosted service (recommended) — Zo will keep it running and give you an endpoint.
Run it in a terminal session (fine for testing, not ideal long-term).

Zo’s “Services” feature is designed for this (web servers, APIs, TCP services, etc.). Start from the Sites/Services docs if you haven’t used it yet. ^4

If your MCP server is HTTP-based

If your MCP server listens on a local port (for example, localhost:3000), register it as a service. This is the same pattern you’d use for any API or web app you host on Zo. ^4

(If you’re reading this inside Zo’s browser UI, you can usually hit http://localhost:<port> directly during testing.)

If your MCP server is STDIO-based

STDIO servers usually expect the client to launch them. To “host” an STDIO server on Zo for use by a remote client, you typically wrap it in an HTTP transport (or run an MCP gateway that exposes it remotely). The official MCP docs include guidance on connecting to remote servers and transports. ^2

Step 4: Connect an MCP client

How you connect depends on your client:

Some clients support remote MCP servers directly (HTTP / Streamable HTTP).
Some only support local STDIO servers.

If your client supports remote MCP servers, you’ll configure it with your Zo service URL and (if needed) auth.

If your client only supports local servers, a common pattern is:

Run the client on your laptop/desktop
Run the MCP server on Zo as a remote HTTP server
Connect over HTTPS/HTTP to Zo

Step 5: Security checklist (don’t skip)

An MCP server is effectively “an API that an AI can call”. Treat it like production.

Prefer read-only tools where possible.
Use least-privilege credentials (separate API keys, scoped tokens, etc.).
Don’t expose file system write/delete tools without strong access control.
If you add authentication, follow the MCP spec’s security and auth guidance. ^2

Troubleshooting

Client can’t connect: verify the Zo service is running; confirm the server is bound to 0.0.0.0 (not just 127.0.0.1) if required by your framework.
Tools don’t show up: confirm your server responds to “list tools” with the correct schema.
Hangs/timeouts: check logs from your server process and make sure it’s returning a response for every request.

What to build next

Once you’ve got a “hello world” MCP server running on Zo, the highest-value next steps are:

A GitHub MCP server for repo search/issues
A database MCP server for read-only analytics queries
A “personal data” MCP server that exposes files, notes, and calendar in a controlled way

If you want MCP-style workflows without building anything, Zo’s core model is already “the AI has tools + your server + your files”, and you can often get 80% of the benefit by creating a prompt or an agent instead of shipping an MCP server.