Which clients does it work with?

Any MCP client. Claude Desktop, Claude Code, Cursor and VS Code all read the same stdio config, and the sse transport covers anything that expects a hosted server.

Can an agent call my production API?

Only if you point it there. Operation tools make real HTTP calls with the credentials you configure, and a write endpoint writes. Set the base URL to staging while you evaluate, and exclude destructive endpoints in SDK Studio so no tool exists for them at all.

How does it stay current?

It reads your published documentation rather than a snapshot, so a spec change that updates your docs updates what the agent sees. There is no separate build step for the server.

What does the agent get that a public spec does not give it?

Your written guides, your changelog, and the real method names from your own SDKs, which is what stops it inventing a call that looks right and does not exist. It also gets the endpoints as callable tools rather than as text to imitate.

The server is free and separately installable. It needs an Octri project to point at, and the free tier covers 50 endpoints.

MCPFrom your spec

Generate an MCP server from your OpenAPI spec

Octri turns the OpenAPI document behind your docs and SDKs into an MCP server, so Claude, Cursor and any other MCP client can read your documentation and call your endpoints. It runs through npx, and the setup is one block of JSON.

Start for free Read the MCP docs

claude_desktop_config.json

{
  "mcpServers": {
    "my-api-docs": {
      "command": "npx",
      "args": ["@octri/mcp", "--project-id", "YOUR_PROJECT_ID"]
    }
  }
}

Spec to server, four steps

One spec, already uploaded for your docs and SDKs, becomes a server an agent can use.

Nothing here is MCP-specific work. The endpoints an agent may reach are the endpoints you already curated for your SDKs, and the documentation it reads is the documentation you already publish. That is the whole reason the setup is this short.

What the server exposes, in depth

Point Octri at your spec
Upload an OpenAPI or Swagger document, paste a URL, or connect the repository it lives in. The same document generates your documentation, your SDKs and this server.
Curate the surface in SDK Studio
Exclude the endpoints an agent should never reach and rename the methods that read badly. The tools are derived from that configuration, so the work is not repeated.
Add the server to your client
One block of JSON with your project id. It runs through npx, so there is nothing to install first and nothing to host.
Restart and ask it something
Claude Desktop and Cursor read their config at startup. Ask the agent to write an integration and watch it read your endpoints instead of recalling an API it saw in training.

What lands in the agent’s tool list

Two kinds of tool, from one document.

Seven tools that read your docs

Search across the published documentation, one endpoint in full with every parameter, the endpoint list filtered by section, the changelog with a switch for breaking changes only, the SDKs you publish, the full text of a written guide, and the real call in your own SDK for one endpoint or all of them.

The seven, by name

One tool per endpoint

Each endpoint you kept becomes a callable tool that performs the real HTTP request. An excluded endpoint has no tool, a renamed method carries your name, and a deprecated one says so. The exclusion list you wrote for your public SDK is the permission list an agent gets.

How operation tools are built

Before you point it at production

Operation tools are not previews. A tool call reaches your live API with the credentials you configured, and a write endpoint writes. Set OCTRI_API_BASE_URL to a staging environment while you are evaluating, and exclude the endpoints an agent should never reach so no tool is generated for them.

Configure it once

Every setting is an environment variable, and only the project id is required.

OCTRI_PROJECT_IDrequired
The project to expose. `--project-id` on the command line overrides it.
OCTRI_API_URLhttps://api.octri.dev/api/v1
Where the server reads documentation from. This is Octri, not your API. Override it when self-hosting.
OCTRI_API_BASE_URLyour SDK Studio base URL
The API that operation tools actually call. Point it at staging while you are evaluating.
OCTRI_API_TOKENnone
Bearer or OAuth2 token for those calls. `OCTRI_API_KEY` and `OCTRI_API_KEY_HEADER` cover key auth instead.
MCP_TRANSPORTstdio
stdio is the default and needs no hosting. Set sse to run one shared instance for a team, with PORT alongside it.

stdio is the default: the client starts the process and talks to it over stdin and stdout, with no ports and no network exposure. Run it over sse instead when a team would rather share one instance than configure their own.

sse transport

MCP_TRANSPORT=sse PORT=3000 OCTRI_PROJECT_ID=YOUR_PROJECT_ID npx @octri/mcp

Nothing to install ahead of time. npx fetches the server on the first run.
The same project id everywhere, so a team’s configs differ only in transport.
Documentation is read live from your project, so there is no snapshot to rebuild.

From the same spec

The same document produces all of it.

A TypeScript SDK

Typed methods on npm, with auto-paging and typed errors.

Read on

Documentation

Reference pages, a live console, search and an agent-readable index.

Read on

A readiness score

Fourteen rules on what a generator can do with your document.

Read on

Questions

No. The server is `@octri/mcp` and runs through npx, so a config block and your project id are the whole setup. There is nothing to build and nothing to deploy unless you choose the sse transport.