How Glxymesh runs MCP servers

Organizations, projects and tools

• An organization owns everything and is what gets billed. People are members of it.
• A project groups tools. Each organization has a default project, and you can create more with gxmesh project create <slug>.
• A tool is a small MCP server written in Go and compiled to WebAssembly. Its name is 1–64 characters of a-z, 0-9 and -, and it’s unique within its project.

One endpoint per project

Clients don’t connect to tools one by one. Each project has a single Streamable HTTP endpoint:

https://mcp.glxymesh.com/mcp/<org>/<project>

The gateway behind it merges every tool in the project into one tools/list and routes each tools/call to the tool that exposes it. When you publish or remove a tool, the list changes, and clients see the change the next time they ask.

A project has a single namespace. If two tools in the same project expose a tool with the same name, the gateway can’t tell which one a call means, so it advertises neither. The gxmesh new template avoids this by naming the MCP tool after the tool itself.

The endpoint accepts POST only. The platform never pushes messages to the client, so there is no GET stream to open.

Authorization without API keys

The endpoint is an OAuth 2.1 resource server. When a client connects:

1. Its first request has no token, so it gets a 401 whose WWW-Authenticate header points to the endpoint’s protected resource metadata.
2. That document names accounts.glxymesh.com as the authorization server.
3. The client registers itself there through dynamic client registration, which is why you never create a client ID.
4. Your browser opens, you sign in and approve, and the client gets a token that belongs to you.

Because each token belongs to a person, there’s no shared secret to rotate. Access is checked on every call: if someone is removed from the organization, their next call fails, and a project they can’t see returns 404, the same as one that doesn’t exist.

The sandbox

Every call runs in a fresh WebAssembly instance with no sockets and no filesystem. Everything a tool can reach outside itself goes through the platform:

Capability	How
Outbound HTTP	host.HTTPClient(), limited to the hosts in manifest.json. See Call external APIs.
Secrets	Environment variables set per project. See Secrets.
State between calls	host.KV. See Store state.
Logs	host.Logf. Logs appear in the console under the tool.
Time and randomness	host.Now() and host.Rand(n).

The tool keeps nothing in memory between calls. Anything it needs to remember has to go in KV.

Building

gxmesh push sends the .go files in the tool’s directory to the platform’s build service. The service compiles them with GOOS=wasip1 GOARCH=wasm against a pinned set of modules and registers the result in the project. The console’s New tool screen uses the same build service, so a tool built from the console and one built from the CLI produce the same module. See Write an MCP tool in Go for which modules you can import and how to push a module you built yourself.