Skip to main content

MCP servers

If your coding agent uses MCP (Model Context Protocol) servers — filesystem access, a GitHub connector, a database browser, your own custom server — they keep working when you point that agent at ZeroSignal. There is nothing to configure and no ZeroSignal-specific setup.

This page explains why that works, what it means for your privacy, and what it costs.

Why it just works​

Your agent is the MCP client, not the proxy. Claude Code, Codex, opencode, Cursor and the rest all do the same thing before sending a request:

  1. Connect to each MCP server you configured and ask what tools it offers.
  2. Turn that list into ordinary OpenAI function tools in the request body.
  3. Send the request.
  4. When the model calls a tool, your agent runs it against the MCP server and sends the result back in a follow-up request.

By the time a request reaches the proxy it contains plain {"type": "function", ...} entries — indistinguishable from any other function tool. The proxy passes them through untouched, and the operator's model calls them like it would any other tool. MCP never appears on the wire at all.

The practical consequence: MCP works with every model on the network that supports tool calling, regardless of which backend the operator runs.

tip

Because your machine runs the MCP server, the operator never sees it. Your filesystem, your database, your API tokens for that server — none of it leaves your device. The operator sees only the tool names and descriptions your agent included in the request, and the arguments the model chose to pass.

What it costs​

Each round of the tool loop is a separate paid request. A conversation that takes three tool calls to answer is four requests: the initial one, plus one after each tool result.

That is worth knowing because the conversation grows each round — every tool result is added to the history — so later rounds cost more input tokens than earlier ones. A long agent session with chatty tools can cost noticeably more than the same question asked directly.

Two things keep that in check:

  • Tool definitions are charged as input tokens. A large MCP server can publish dozens of tools with long descriptions, and all of it rides in every request. If a session feels expensive, trimming which MCP servers your agent loads is the biggest lever you have.
  • Your escrow is sized to the actual request. The proxy reserves based on what you're really sending, so a function-tool request doesn't lock up your balance for a tool loop the operator was never going to run.

See Seeing what you paid to check any of this against real numbers.

The other kind: remote MCP​

There is a second, much rarer thing also called MCP. The OpenAI Responses API accepts an mcp tool type that points at a URL:

{ "type": "mcp", "server_label": "github", "server_url": "https://..." }

Here the model provider — not your machine — connects to the MCP server and runs the tools. ZeroSignal forwards these entries unchanged and does not charge a per-call fee for them, but two caveats apply:

  • It only works on some operators. Only operators fronting a hosted API that implements remote MCP (in practice, OpenAI) can honour it. An operator running vLLM, llama.cpp or a similar self-hosted backend will ignore or reject it — those servers have no remote-MCP support, and the routing layer can't yet tell which operators do.
  • Your credentials travel. Any auth token you put in the entry's headers goes to the operator's upstream provider, which then calls your MCP server with it. That is a different trust boundary from client-side MCP, where the server is only ever reached from your own machine.
warning

If you have the choice, prefer client-side MCP — the way every coding agent does it by default. It works everywhere on the network and keeps the MCP server, and its credentials, on your machine.

Some operators cap how many remote-MCP calls one request may make; most don't, so a long session is bounded only by what you're willing to spend — each call feeds its results back into the conversation, and you pay for those tokens like any other input. See Per-call tool pricing for the operator's side of this.

If a tool goes missing​

If the model behaves as though a tool you sent doesn't exist, the likeliest cause is that the operator stripped it. Operators strip vendor-hosted tools they haven't priced — things like the provider's own web_search or code_interpreter — so they aren't billed for something they didn't opt into.

Ordinary function tools, including everything your agent derived from MCP, are never stripped. So this only bites if you (or your tool) sent a provider built-in directly. Either drop it, or pick an operator that prices it.

What's next​