Get started

Spacefix documentation

Connect the functions you already have to Claude, Cursor and every other MCP client, without building or hosting an MCP server.

Spacefix turns code you already run into an MCP server. You add a small SDK to your service, it opens one connection out to us, and any MCP client (Claude Code, Claude Desktop, Cursor, VS Code, the MCP Inspector, or code you write) can call your functions through a URL we host. You open no inbound port, deploy nothing new, and your code, database and secrets stay in your own process.

#How it works in a minute

1. Register. In your service, tell the SDK which tools (and optionally resources and prompts) to offer, and give it an agent key from your project.
2. Connect. When your service starts, the SDK opens one outbound HTTPS connection to the gateway and announces what you offer. The connection stays open. Your project page turns Connected.
3. Call. An MCP client calls your project's URL, https://api.spacefix.io/mcp/<project id>, with a client key. The gateway checks the key and the arguments, sends the call down the connection you opened, your function runs in your process, and the answer comes back the same way.

The tools you register are plain functions in your language. A tool is typically a thin call into code you already ship and test:

agent.tool(
  'get_order',
  { description: 'Look up one order by its id.', inputSchema: z.object({ id: z.string() }) },
  ({ id }) => orderService.findById(id)
);

core.AddTool(agent, "get_order", "Look up one order by its id.",
	func(ctx context.Context, in GetOrderInput) (Order, error) {
		return orderService.FindByID(in.ID)
	})

The Quickstart takes you from nothing to a first call in about ten minutes.

#Who it is for

• Teams that already have services and want AI clients to use them, without writing and operating a second service just to speak MCP.
• Platform and security teams that will not open an inbound path to their network or ship code to a third party.
• Teams that want to see and control what models do with their tools: which tools are called, how often, how fast, and by which key.

Your service has to run as a long-lived process (containers, VMs, Kubernetes, and similar), because the connection is long-lived. Request-scoped serverless platforms that freeze the process between requests cannot hold it open. In that case run the agent as a small always-on worker next to your API.

#What stays in your network

Nothing you write is uploaded or runs on our side. The one place your data is held for a moment is the optional per-tool result cache, which you turn on yourself. See Concepts for the full list.

#What it does not do

Knowing the limits up front saves a redesign later:

• Handlers do not know who called them. A call carries the tool name and arguments, not the caller's identity. Pass any identity you need as an explicit argument.
• No streaming. A tool returns one result. See the FAQ.
• Tools, resources and prompts only. Sampling, elicitation and change notifications are not supported. Tool annotations are. See the FAQ.
• One more hop. A call goes client, gateway, your service and back. It suits lookups and actions, not chatty high-frequency traffic.
• A dependency on the gateway. If your service is off, its tools are unreachable; if the gateway is unreachable, your application itself is unaffected but the MCP surface is not.

#SDKs

You can also connect without an SDK by speaking the agent protocol directly; it is documented under Reference.

#Map of the documentation

The sidebar lists every page, including the guides on observability, alerts, plans and limits, security and troubleshooting.