MCP Server

The Nym docs MCP (opens in a new tab) server lets an AI coding agent search the Nym documentation and read live network state as structured tool calls. You do not paste doc links, and the agent does not guess at API shapes. Point it at one URL:

https://nym.com/docs/api/mcp

It exposes two kinds of tool:

• Documentation retrieval: semantic search over the docs corpus, returning ranked excerpts with deep-link URLs back into these pages.
• Live network data: bonded node counts, gateway health, token supply and chain status, read from the Nym APIs at call time.

The live tools are the reason to use this over a static llms.txt. An agent can ask "is gateway X in the active set right now?" and get a current answer. A static file can only give a snapshot baked in at build time.

Transport

Streamable HTTP: a single endpoint that accepts JSON-RPC 2.0 (opens in a new tab) over POST. The server is stateless, so there is no session to establish. A request must advertise both response content types in its Accept header, or the server replies 406:

Accept: application/json, text/event-stream

The reply comes back as a Server-Sent Events frame (event: message / data: {...}) carrying the JSON-RPC result.

Connecting your agent

Most clients take an MCP server as an entry in a JSON config file. The shape is the same across clients:

{
  "mcpServers": {
    "nym-docs": {
      "type": "http",
      "url": "https://nym.com/docs/api/mcp"
    }
  }
}

• Claude Code: add it from the CLI, or drop the entry above into .mcp.json at your project root.

  claude mcp add --transport http nym-docs https://nym.com/docs/api/mcp
• Cursor: add the entry above to .cursor/mcp.json in your project (or the global ~/.cursor/mcp.json), then enable the server in Settings.
• Other clients: consult your client's MCP setup docs; supply the URL above as a Streamable HTTP (not stdio, not SSE) server.

After connecting, ask the agent to list the server's tools to confirm the connection.

Tools

Raw examples

The endpoint speaks plain JSON-RPC, so you can exercise it with curl before wiring up an agent.

List the tools:

curl -sS -X POST https://nym.com/docs/api/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Call a tool (search_docs):

curl -sS -X POST https://nym.com/docs/api/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"search_docs","arguments":{"query":"how do I set up mixFetch"}}}'

How search works

search_docs and search_code are semantic rather than keyword. Both sides of a comparison have to become vectors before similarity means anything, so the embedding happens in two places.

At deploy, every documentation section and every indexed source file is embedded once and written into a static index. At call time, your query is embedded with the same model, and the server ranks the index against that vector by cosine similarity.

your agent ──JSON-RPC──▶ /docs/api/mcp ──▶ embed the query
     ▲                         │                  │
     │                         │◀── query vector ─┘
     │                         │
     │                         ├─ rank the prebuilt index by similarity
     │                         │
     └───── ranked sections ───┘

The code index uses a model trained on source rather than prose. That is why search_code surfaces implementation details a prose model ranks poorly, and why the two indexes are kept separate instead of merged.

Query and index must come from the same model. A query embedded with one model and scored against an index built with another returns neighbours that are not meaningfully related.

There is no vector database. The index is a static file loaded once per server instance, so a search costs one embedding call and an in-memory scan.

What it costs you

Nothing beyond your own agent's tokens. The endpoint is open: no API key, no account, no request signing. Point a client at the URL and call it.

The server embeds your query using its own credentials, so the retrieval side is paid for by Nym. Your agent spends what it would spend anyway, reading the returned sections and writing an answer from them.

That split is deliberate. The server returns raw documentation sections and performs no generation of its own: it retrieves and cites, your agent reasons. It also keeps results checkable, because every one carries a deep link to the section it came from.

Notes

• Docs coverage. search_docs indexes the public Nym developer and network documentation. Answers cite the exact section, so you (or the agent) can open the source page and read it in full.
• Live-data freshness. The network tools query the Nym APIs on each call, so results are as current as those APIs. A tool that cannot reach its upstream returns an error result the agent can read and retry on, rather than failing the whole request.
• Not a write interface. Every tool is read-only. The server cannot change network or chain state.
• Retrieval granularity. Ranking operates on whole sections, so an answer is only as good as the section backing it. See How search works.