Use the docs with AI
The Nym docs MCP 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/mcpIt exposes two kinds of tool:
- Documentation retrieval: semantic search over the docs corpus, returning ranked excerpts with deep-link URLs back into the 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. The endpoint is open: no API key, no account. Claude Code, Cursor and others are supported.
Tools
| Tool | Parameters | Returns |
|---|---|---|
search_docs | query (string, required); topK (number, default 6) | Ranked documentation excerpts, each with its section heading and a deep-link URL. Use first for any “how do I / what is” question. |
get_section | ref (string, required): a chunk id or deep-link URL from search_docs | The full text of one section, when a search excerpt is truncated. |
search_code | query (string, required); topK (number, default 6) | Ranked excerpts from selected Nym source (SDK, wasm, Sphinx, smolmix crates and examples), each with a GitHub deep link. Use when the question is about implementation rather than documented behaviour. |
network_summary | none | Live counts of bonded nym-nodes: total, gateways, mixnodes, entry and exit. These are independent counts reported by the Node Status API, not a breakdown, so they overlap and do not sum to the total. |
circulating_supply | none | Live circulating and total NYM token supply. |
chain_status | none | Live Nyx chain connection status as seen by the Nym API. |
list_gateways | page (number, default 0); size (number, default 20) | A page of bonded gateways with performance and routing scores. |
get_gateway | identity (string, required): gateway identity key | Health and scores for a single gateway. |
validate_sdk_config | config (object, required): a SetupMixTunnelOpts object | Flags field type mismatches (errors) and unknown or typo’d keys (warnings), and notes privacy tradeoffs. Run before writing a mix-tunnel / mix-fetch config into code. |
How search works
search_docs and search_code are semantic rather than keyword. 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. 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.
| Index | Model | Covers |
|---|---|---|
| Documentation | voyage-3-large | every published docs page, chunked by section |
| Source code | voyage-code-3 | selected Nym crates: SDK, wasm, Sphinx, smolmix, and their examples |
Notes
- Docs coverage.
search_docsindexes 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.