An MCP server for your API, built from your spec
One Model Context Protocol server hands Claude, Cursor, VS Code and any other MCP client your published documentation to read and your endpoints to call, both generated from the same OpenAPI document your docs and SDKs come from.
npx @octri/mcp with your project id, and nothing to install first
What the agent reads
Seven documentation tools
Search your published pages, open one endpoint in full, pull the changelog, and fetch the real SDK snippet for the call it is about to write.
Docs as contextWhat the agent calls
One tool per endpoint
Every endpoint you include becomes an executable tool with a typed input schema, named the way your SDK names it, performing the real HTTP request.
API as toolsWhat you decide it can reach
Three levers, one list
The environment it points at, the credential it carries, and the endpoints on the list. Your SDK exclusions are already the agent permissions.
Scope and controlThe agent works from the docs you published
Point an MCP client at your project id and seven read-only tools appear. They serve your published pages and your published guides, at the version your readers are on, so an answer an assistant gives about your API is one you could have written yourself.
- A project id is the entire setup. No credentials, no account on our side, no keys in the config
- Whole pages come back, with every parameter, the responses and the runnable examples that sit on them
- The real snippet for your SDK, so the call an agent writes uses the method name your users will find
- Your changelog, breaking entries included, which is what turns “what do I change to upgrade” into a sourced answer
- Drafts stay invisible. Unpublished means unpublished for agents as much as for readers
- Available the moment a project exists, on every tier, with nothing to enable
Seven tools, the same in every project
These ship with the server. They need no credentials and they have no side effects, so connecting one to an assistant costs you a config file and nothing else.
search_docs
A natural language query across the published documentation, with the number of results the agent asks for.
get_endpoint
One endpoint in full: the description, every parameter with its own prose, the responses, and the code examples on the page.
list_endpoints
The endpoint list, filterable by section, which is how an agent finds a slug to look anything else up by.
get_changelog
Recent API changes, with a switch for the breaking ones only, so an upgrade question has a source to answer from.
list_sdks
The client libraries you publish, their versions and where to download them.
get_guide
The full text of a written guide by slug, including the guides that live inside a section.
get_sdk_methods
The real call, in your own SDK, for one endpoint or all of them, in one language or every language you generate. Method names, argument style and client shape are the ones your users get.
Under these sits the second list, which is the one that belongs to your project.
Your endpoints as toolsEvery endpoint you ship becomes a tool it can call
Past reading, the server exposes one executable tool per included endpoint. The agent is handed the method name, the description you authored and a JSON Schema for the arguments, and calling it performs the real HTTP request against your API.
- Named the way your SDK names it, so the tool an agent calls and the method a developer calls are one word
- A typed input schema built from the path, query and body of the operation, carrying enums, formats and your examples
- The description is your prose, taken from what you wrote in API Studio, which is most of how an agent chooses between two tools
- Documented failures travel with it, up to eight per tool, so a 422 with a name is something an agent can act on
- A deprecated operation says so, with the note you left about what to reach for
- Your auth scheme is wired in, whether that is a bearer token, an API key under your own header, OAuth2 or basic
New endpoints arrive as tools
An operation you add to your spec is callable as soon as you publish. Anything outside your SDK stays outside, and there is no second list of agent tools to keep in step.
Write operations included
A create endpoint creates and a refund endpoint refunds. Every operation in your SDK is callable, so an agent can carry a task through to a real result.
Values you pin
A value you fix on an operation travels on every call without appearing in the tool inputs. An account id or a source tag stays your decision.
Failures come back readable
When your API rejects a call, your status and your error body reach the agent, so it can correct the arguments and try again.
The tool list is a decision you already made
Operation tools are built from the same configuration as your SDKs. The names, the descriptions, the exclusions and the deprecations are read from what you set in the studios, so the agent surface is curated by the work you did on the client library.
- An endpoint left out of the SDK has no tool, which makes your exclusion list the list of things an agent can do
- A method you renamed keeps that name here, through the same order the generator follows: your override, then a spec transform, then the operationId
- Preview it while you configure it, on the studio's Agent tab, which builds the tools from your draft
- Previewed, downloaded and served are the same tools, because one builder produces all three
- Nothing new to fill in. The agent surface has no settings screen of its own
Three levers decide how far an agent gets
An agent will call what it is given, and the tool list is the set of things you are comfortable happening unattended. Three controls set that list and where it points, and they run from the one you can change in a second to the one that is permanent.
- The credential stays on the machine that runs the server, in your own client config, and never reaches us
- The server holds no session with your Octri account. It reads a published tool list by project id and can see nothing else in your dashboard
- Published content only, on both halves, so a draft page and a draft SDK config are both out of reach
- Without a credential the server still runs, and everybody gets the seven documentation tools with nothing executable behind them
Point it at staging
One variable decides which environment every operation tool reaches. This is the control to reach for first, and the one worth setting in any config you commit.
Scope the credential
The agent can do whatever its key can do. A narrow, revocable one gives it exactly the reach the job needs and stops there.
Exclude the endpoint
An operation that should never be agent-reachable comes out of the SDK, and the tool stops existing. This is the one an agent cannot talk its way around.
One config file, and the tools appear
The server is published as @octri/mcp and runs through npx, so there is nothing to install ahead of time. Add it to the client you already use and restart.
- Claude Desktop reads
claude_desktop_config.json - Cursor reads
.cursor/mcp.json, per repository or for every project you open - VS Code reads
.vscode/mcp.json - A flag or an environment variable for the project id, whichever the config suits, and the flag wins if both are set
- Commit the config without the credential, so a repository gives every contributor the documentation tools and each person adds their own key
Every variable, and what happens when one is missing. MCP guides in the docs →
On your machine, or on one machine for the team
The default needs no hosting at all. The second exists for teams who would like one instance to serve everybody, with a single config to keep current.
stdio, the default
The AI client starts the process and talks to it over stdin and stdout. No ports, no hosting, no listening surface, and each person's credentials stay theirs. This is what Claude Desktop and Cursor use.
sse, when you host it
Set the transport and a port and the server listens, so a team connects to one URL and nobody edits a config file. You run it, which means you choose where it sits and what it can reach.
The useful shared deployment
A hosted server with no credentials at all
A hosted server calls your API with whatever credential it was started with, on behalf of everyone connected, and your API logs will attribute all of it to that one identity. Start it with a project id and nothing else and the whole team gets shared documentation context with no shared reach, then anyone who wants the executable half runs their own copy locally with their own key.
- One URL for the team, and one place to update it
- The seven documentation tools for everybody
- Operation tools stay individual, with each person's own credential
- Your API logs keep naming real people
Run a tool before an agent ever does
Your project has an MCP page in the dashboard listing every tool the server serves. You can pick one, fill in its arguments, send it, and read what came back, which is the difference between a tool definition that looks right and one you have watched work.
- Both halves in one list, the seven documentation tools and every operation tool your configuration kept, with a filter over them
- Send a real request and keep the transcript, so the status and the body are there to compare against the next attempt
- Write methods ask twice, since the call this page makes is as real as the one an agent makes
- The config file, already filled in with your project id and the variables your auth scheme needs, ready to copy into your client
- It tells you what is still a placeholder, so a paste that would have failed quietly gets flagged before you leave the page
The same tools, in the shape your framework wants
Plenty of agents are something you wrote yourself. One public endpoint serves your project's tool list, and a query parameter decides whether it arrives as MCP tools, OpenAI function definitions or Anthropic tool definitions.
- MCP, which is name, description and inputSchema, ready for any MCP client you are building
- OpenAI, as function definitions for function calling
- Anthropic, as tool definitions with input_schema
- Or the full form, which adds the execution mapping our own server uses to turn a tool call into an HTTP request
- Downloadable from the dashboard too, one file per format, for checking into a repository beside the agent that loads it
Read-only and public
It reflects your published configuration and carries no credentials, which is what lets a server on somebody else's laptop read it with only a project id. It serves 300 requests a minute per client and caches for two minutes.
One merged PR, and the tools change with it
Connect the repository your OpenAPI document lives in and a merged pull request is all it takes. The endpoint you added is a tool the next time an assistant starts, described by the page that was written for it in the same run.
- One merged PR rebuilds the pages, the clients and the tool list together, in under 90 seconds
- Available on every tier, Free included
- A publish pins what agents see, so the tools track your released configuration while you carry on editing the draft
- Deprecate an operation and the tool says so before the release that removes it
MCP is one of four ways in
A connected assistant is the richest of them and it is the one somebody has to set up. The others are on by default, and they come off the same spec.
An index built for models
Your docs site serves a machine-readable index of itself, and every page has a markdown form a model can take whole.
Ask the docs
A chat on your own documentation, grounded in your spec and your pages, for readers who are already there.
Snippets in ten languages
The call in your own SDK on every reference page, which is what get_sdk_methods hands back and what a reader copies.
What the calls did
Monitoring picks up what production actually hit, whether the request came from a person, an SDK or an agent.
And the parts you only notice when they are missing
Reading
- Scope a listing to one section, so a large API is still navigable
- Ask for breaking changes only, when the question is an upgrade
- Fetch a guide that lives inside a section, by its two slugs
- Narrow snippets to one endpoint, one language, or neither
Calling
- Path, query and body inputs kept apart, so the request is built the way your API reads it
- Enum values, formats and examples carried into the schema from your spec
- Values you baked into an operation sent every time and never shown to the agent
- A tool name coerced to the MCP charset, capped at 64 characters and deduplicated
Running it
- A flag or an environment variable for the project id, whichever suits the config
- A port of your choosing when you host it and 3000 is taken
- A self-hosted Octri reached by pointing one variable at it
- The server run on its own, to read what it reports with no client in the way
Your agent tools are current because nobody maintains them
The pages an agent reads and the tools it calls are both by-products of shipping your documentation and your client libraries. There is no agent surface to maintain, no second description of an endpoint to keep in step, and no moment where the tool list is a version behind the API, because all of it is generated from the document you already merged.
Questions
Every tier, Free included, and there is nothing to switch on. What your plan decides is how many endpoints have documentation pages, since operation tools are built from those: 50 on Free, 250 on Starter, 1,000 on Growth and 2,500 on Business. The seven documentation tools are the same on all of them.
Somebody is integrating your API with an assistant open
This is what it reads while they do it.