This server exposes an API's documentation, endpoints, guides, SDKs, and changelog as MCP tools an AI assistant can call.
Search the docs — search_docs runs a natural-language query to find an endpoint or concept (with a result limit).
Read an endpoint — get_endpoint returns full documentation for one endpoint by slug.
Browse endpoints — list_endpoints lists all endpoints, optionally filtered by section/tag.
Check changes — get_changelog returns recent API changes, with an option for breaking changes only.
See available SDKs — list_sdks lists client library languages, versions, and download links.
Read guides — get_guide fetches the full content of a tutorial or conceptual doc by slug.
Get SDK code — get_sdk_methods returns ready-to-use snippets per endpoint in every supported language, filterable by endpoint slug or language.
Target a project — every tool accepts an optional projectId, defaulting to the project the server was started with.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@octri/mcp search the API docs for the create user endpoint"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that turns your API documentation into tools an AI assistant can call. Claude, Cursor, VS Code Copilot, and any other MCP client can search your endpoints, open a guide, pull a ready-to-use SDK snippet in any supported language, and check the changelog for breaking changes, all from the same OpenAPI spec your docs are built from.
Octri turns an OpenAPI spec into a documentation site, client SDKs for ten languages, an MCP server your AI assistant can call, and monitoring for the API behind them. This package is the MCP server. See octri.dev/mcp.
Node 20 or newer. Runs over stdio for a local client, or Streamable HTTP when you host it.
npx -y @octri/mcpMost clients are configured with that command, so a global install is optional. The Installation section below has the exact config block for each one.
Or install it in one click. VS Code asks for your project ID; Cursor writes
YOUR_PROJECT_ID into its mcp.json for you to replace.
Listed in the official MCP Registry as dev.octri/mcp.
Related MCP server: mcp-swagger
Tool | Description |
| Search the API documentation for an endpoint or concept |
| Get full documentation for a specific API endpoint |
| List all available API endpoints, optionally filtered by section |
| Get recent API changes and breaking changes |
| List the available SDK client libraries (languages, versions, download links) |
| Get the full content of a written guide by its slug |
| Get ready-to-use SDK code snippets for each endpoint in every supported language |
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"my-api-docs": {
"command": "npx",
"args": ["@octri/mcp", "--project-id", "YOUR_PROJECT_ID"]
}
}
}Add to .cursor/mcp.json in your project root (or ~/.cursor/mcp.json globally):
{
"mcpServers": {
"my-api-docs": {
"command": "npx",
"args": ["@octri/mcp"],
"env": {
"OCTRI_PROJECT_ID": "YOUR_PROJECT_ID"
}
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"my-api-docs": {
"type": "stdio",
"command": "npx",
"args": ["@octri/mcp", "--project-id", "YOUR_PROJECT_ID"]
}
}
}Variable | Required | Default | Description |
| Yes* | None | The project to connect to. Can also be set via |
| No |
| Override the API base URL (useful for self-hosted deployments). |
| No |
|
|
| No |
| HTTP port for the |
| No |
| Interface to bind. Widening it requires |
| No | None | Comma-separated browser origins allowed to reach an HTTP transport. |
| When | None | Bearer token every HTTP request must send as |
* Required unless every tool call passes projectId explicitly.
Operation tools call your real API, and these supply its credentials:
Variable | Description |
| Target API base for operation calls (falls back to the studio's Base URL). |
| Bearer / OAuth2 token. |
| API-key value, and the header it goes in (default |
| Basic-auth credentials. |
All of these are sent as HTTP headers. An API that takes its credentials in
the request body instead (Plaid's client_id and secret, for example) is
not served by them: those are ordinary body fields, so they appear as tool
arguments and the agent passes them like any other field. Setting
OCTRI_API_KEY for such an API adds a header it ignores.
Use Streamable HTTP (MCP_TRANSPORT=http), the transport the MCP spec has
defined for remote servers since revision 2025-03-26 and the one a current
client tries first:
docker build -t octri-mcp .
docker run -p 3000:3000 \
-e MCP_TRANSPORT=http \
-e OCTRI_PROJECT_ID=YOUR_PROJECT_ID \
octri-mcpIt serves a single endpoint, POST /mcp, and runs statelessly, so requests
carry no session and any number of replicas can sit behind a load balancer.
Point a remote MCP client at http://your-host:3000/mcp.
MCP_TRANSPORT=sse serves the older 2024-11-05 design, kept so existing
deployments keep working. It exposes GET /sse to open a connection and
POST /messages?sessionId=<id> to relay client messages. Prefer http for
anything new.
Both HTTP transports bind 127.0.0.1 by default and refuse any request whose
Origin is not listed in MCP_ALLOWED_ORIGINS, or whose Host is not
loopback. This server holds your API credentials, and any page the browser
visits can reach a loopback port.
Widening MCP_HOST puts those credentials on the network, so the server then
refuses to start without MCP_AUTH_TOKEN, and every request must send
Authorization: Bearer <token>. Configure the same header in your MCP client,
and list browser origins explicitly.
# Build
pnpm build
# Run in stdio mode
OCTRI_PROJECT_ID=my-project node dist/index.js
# Run in Streamable HTTP mode (POST /mcp)
MCP_TRANSPORT=http OCTRI_PROJECT_ID=my-project node dist/index.js
# Run in the legacy SSE mode
MCP_TRANSPORT=sse OCTRI_PROJECT_ID=my-project node dist/index.jspnpm build
npm publish --access publicRequires an npm account with access to the @octri scope.
Product | What it does |
Your OpenAPI spec becomes a hosted documentation site with a live request playground, editable page by page. | |
The same spec becomes client libraries for ten languages, versioned and released together. | |
Your endpoints and docs become tools an AI assistant can call, generated from the same spec. | |
Errors, traces, uptime and releases for the API, joined to the SDK calls that reached it. |
Node · Python · Go · Ruby · Rust · PHP · Java · Kotlin · Swift · Dart
Documentation · Pricing · Changelog
MIT licensed.
Get recent API changes and breaking changes
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project to read. Optional — defaults to the project this server was started with. Only pass it to target a different project. | |
| breakingOnly | No | Only return entries with breaking changes (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the description does not need to restate safety. It adds a scoping detail ('recent') and the breaking-changes filter, but does not disclose return format, pagination, or ordering. With strong annotation coverage, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the core operation. Every word earns its place and there is no boilerplate or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with zero required parameters and fully documented optional parameters, the description provides enough to invoke it correctly. It lacks an explicit return-shape description, but no output schema exists to fill that gap; this is a minor omission for a straightforward changelog getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains projectId and breakingOnly fully. The description adds no additional parameter meaning, which is fine because the schema bears the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Get') and a specific resource ('recent API changes and breaking changes'), making the tool's role as a changelog reader clear. This distinguishes it from siblings like search_docs, get_endpoint, and list_sdks without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'recent API changes' implies the tool should be used when the agent needs the latest changelog, and the breaking-only filter hints at a filtering use case. However, it does not explicitly state when to prefer this over siblings such as search_docs or get_guide, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full documentation for a specific API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The endpoint slug | |
| projectId | No | Project to read. Optional — defaults to the project this server was started with. Only pass it to target a different project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which fully cover the safety profile. The description adds no additional behavioral context beyond stating the read nature ('Get'). It is consistent with the annotations and does not contradict them, but it doesn't enhance transparency beyond what structured data already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-written sentence: 'Get full documentation for a specific API endpoint.' It wastes no words, is naturally front-loaded, and the core action and object are immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with only two parameters and no output schema, the description is adequate. It clearly communicates the tool's purpose, and the annotations cover behavioral guarantees. It doesn't detail the return format or edge cases, but that is not critical given the low complexity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning both parameters (slug and projectId) are fully documented in the schema. The description adds no parameter-specific semantics or clarifications beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a clear resource ('full documentation for a specific API endpoint'). It clearly indicates the tool retrieves documentation for a single endpoint, which distinguishes it from siblings like list_endpoints (which lists) and search_docs (which searches). However, it does not explicitly name alternatives or differentiate itself in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for retrieving documentation of a specific endpoint identified by slug, but it doesn't mention when not to use it or point to other tools. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full content of a written guide (tutorial / conceptual doc) by its slug
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The guide slug (from list_endpoints) | |
| groupSlug | No | The guide's section slug, if it belongs to one | |
| projectId | No | Project to read. Optional — defaults to the project this server was started with. Only pass it to target a different project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by specifying that it returns the 'full content' of a guide, implying a complete representation rather than metadata or a summary. This reinforces the readOnly and idempotent hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the core action and resource. Every word adds value, and there is no redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with full schema coverage and strong annotations, the description is adequately complete. It specifies the resource, the lookup key, and the full-content nature of the response, though it does not describe error cases or response formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents all three parameters. The description itself only adds the context of fetching 'by its slug', which aligns with the required parameter without providing additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('written guide') and further clarifies the resource type as 'tutorial / conceptual doc'. It clearly distinguishes this from endpoint, SDK, and changelog tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this when you need the full content of a guide by slug. However, there is no explicit guidance about when to prefer get_guide over search_docs, nor when groupSlug or projectId should be provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show how to call this API through its generated SDKs. Ready-to-use code snippets per endpoint in every supported language. Use slug (from list_endpoints) to focus on one endpoint, and language (e.g. typescript, python, go) to focus on one language.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Focus on a single endpoint by its slug. Omit to return all endpoints. | |
| language | No | Focus on one SDK language (e.g. typescript, python, go). Omit for all supported languages. | |
| projectId | No | Project to read. Optional — defaults to the project this server was started with. Only pass it to target a different project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds that the tool returns code snippets scoped by endpoint and language, which is useful but does not detail output format, ordering, or behavior when all parameters are omitted. This is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, and the following sentences provide actionable parameter guidance without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple read-only tool with optional parameters and rich schema descriptions, the description covers the essential usage. It explains what the tool produces, how to narrow results, and where to obtain valid slug values. No critical guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds value by telling the agent that the slug comes from list_endpoints and by giving concrete language examples (typescript, python, go), which helps correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: showing how to call the API via generated SDKs and providing ready-to-use code snippets per endpoint and language. It also references list_endpoints as the source of slugs, helping distinguish this tool from nearby siblings like get_endpoint or list_endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage context: use the slug to focus on one endpoint and the language parameter to focus on one language, with examples. It does not explicitly describe when not to use this tool or contrast it with alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available API endpoints
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Filter by section/tag name | |
| projectId | No | Project to read. Optional — defaults to the project this server was started with. Only pass it to target a different project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond the name: no mention of filtering, ordering, pagination, or the shape of the returned listing. With no output schema, the agent gets no additional insight into what happens when this tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no filler or repetition. It front-loads the core action and resource, earning its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-optional-parameter list tool, the combination of the one-sentence description, full schema documentation, and safety annotations is mostly sufficient. The only minor gap is the lack of an output schema and no description of the return value structure, but 'List all available API endpoints' conveys the expected result adequately for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both section and projectId are already fully documented in the structured data. The description adds no parameter-level meaning, but since the schema carries the burden, the baseline of 3 is appropriate. There is no need for the description to repeat what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('all available API endpoints'), making the tool's purpose immediately obvious. It also distinguishes itself from siblings like get_endpoint (which implies a single endpoint) and list_sdks (which lists SDKs). No ambiguity remains about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like get_endpoint or search_docs. The description gives no explicit conditions, exclusions, or preferred scenarios, leaving the agent to infer usage from the name and siblings. This is a significant gap for a tool that could easily be confused with get_endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available SDK client libraries for this API (languages, versions, and download links)
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project to read. Optional — defaults to the project this server was started with. Only pass it to target a different project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description carries little safety burden. It adds a useful hint about the list contents, but it does not mention potential variability, limits, or behavior when projectId is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. The core action and result contents are front-loaded and everything included earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with no required parameters and strong annotations, the description is largely sufficient. It defines the output content and purpose, though it could mention whether the optional projectId changes the returned SDK list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (projectId) with a complete description, so the baseline applies. The tool description does not add further parameter-level meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('SDK client libraries') with details about contents (languages, versions, download links). It clearly distinguishes from siblings like list_endpoints and get_sdk_methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when the agent needs available SDK client libraries for the API—but it does not explicitly state alternatives or exclusions. Sibling tools like get_sdk_methods could plausibly overlap, so some routing guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the API documentation for an endpoint or concept
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 5) | |
| query | Yes | Natural language search query | |
| projectId | No | Project to read. Optional — defaults to the project this server was started with. Only pass it to target a different project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no behavioral context beyond purpose—no mention of result format, pagination, or whether the search is scoped to a specific project. Since annotations carry the safety information, this is a gap, but not a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence. It front-loads the verb and resource, contains no filler, and every word contributes meaning. This is an efficient definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with complete schema annotations and a read-only, idempotent profile, the description adequately states the core action. However, with no output schema, the agent is left to guess what the result structure looks like (e.g., snippets, links, relevance scores). This is a modest gap, but not a major one for a simple search operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, so the baseline is 3. The description adds slight value by clarifying that queries can target an 'endpoint or concept', which hints at the expected query semantics, but it does not meaningfully supplement the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search'), a clear resource ('API documentation'), and a scope ('endpoint or concept'). This distinguishes it from sibling tools like get_endpoint and list_endpoints, which are all retrieval/list operations, whereas this is a search operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_endpoint or list_endpoints. It does not state whether to use it when the endpoint path is unknown or how it relates to the sibling tools, leaving the agent to infer routing from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.1get_changelogget_endpointget_guideget_sdk_methodslist_endpointslist_sdkssearch_docsScored across 7 tools
Each tool targets a distinct resource: changelog, endpoint docs, guides, SDK methods, endpoint listings, SDK listings, and search. No two tools appear to overlap in purpose, so an agent can reliably select the right one.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (get_, list_, search_). The verbs are clear and the nouns are specific, making the naming predictable and uniform.
With 7 tools, the set is well-scoped for an API documentation server. Each tool serves a clear function without redundancy, and the count falls comfortably within the ideal 3-15 range.
The tool surface covers the core documentation workflows: discovering endpoints, retrieving details, searching, accessing guides, checking changelog, and SDK info. The only notable gap is the lack of a list_guides tool, though search_docs can partially compensate.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Discover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
