How to create MCP API documentation in one click, without hosting a server

MCP API documentation is the machine-readable description an AI assistant reads to know how to call your data: the tools it can invoke, the arguments each one takes, and the shape of what comes back. Normally you produce that by building an MCP server, hand-writing its schema, wiring up authentication, and hosting it somewhere that stays online. With KBrain, creating a brain generates that documentation and hosts the server for you. There is nothing to deploy.

What MCP API documentation actually is

An MCP server does not ship a PDF or a wiki page. Its documentation is structured and machine-readable. A client calls a discovery method, tools/list, and gets back every tool the server exposes, each with a name, a description, and a JSON Schema for its inputs. That schema is the contract. It is how an assistant knows that search_knowledge takes a query string, or that one argument is optional. For ChatGPT Actions, the same role is played by an OpenAPI document. Either way, the assistant reads the spec, not prose, and calls the tool directly.

So the real question is not how to write that documentation by hand. It is how to generate it, keep it in sync with what the server actually does, and serve it from somewhere reliable.

The usual way: build and host a server

Doing this yourself is a real project, not a one-liner.

• Define the tools and hand-write a JSON Schema for every argument, then keep those schemas correct as the code changes.
• Implement an OAuth flow so an assistant can authenticate without pasting secrets into the chat.
• Deploy the server and keep it online, because a knowledge tool that is down is a tool the assistant silently cannot use.
• Maintain the documentation separately, and hope it does not drift from what the endpoints really return.

The one-click way

On KBrain you create a brain by uploading documents, connecting a source like Google Drive, or subscribing to one from the marketplace. That single action produces a hosted MCP endpoint whose documentation is generated from the brain, not written by you.

• A hosted MCP endpoint, one URL, that KBrain keeps online for you.
• A discoverable tool schema: list_brains and search_knowledge, each with a typed JSON input schema and read-only annotations, returned by tools/list.
• An OpenAPI 3.1 document for ChatGPT Actions, with typed operations and response schemas.
• An OAuth security scheme, wired automatically, so the connection authenticates without secrets in the chat.
• One connector that covers every brain you subscribe to, with no per-brain setup.

What the generated documentation looks like

When an MCP client connects, it calls tools/list and receives the tools KBrain exposes for your brain. Here is a trimmed view of the search_knowledge tool and its input schema, exactly the contract the assistant reads:

{
  "name": "search_knowledge",
  "description": "Retrieve knowledge from one connected brain.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query":    { "type": "string", "description": "What you are looking for, in plain language." },
      "brain_id": { "type": "string", "description": "Connected brain id. Optional when you have one brain." }
    },
    "required": ["query"]
  },
  "annotations": { "readOnlyHint": true }
}

For ChatGPT, the same brain is described by an OpenAPI 3.1 operation. The queryBrain operation, again generated for you, looks like this:

"/api/chatgpt/v1/brains/{brainId}/query": {
  "post": {
    "operationId": "queryBrain",
    "summary": "Query one selected brain",
    "requestBody": {
      "content": { "application/json": {
        "schema": {
          "type": "object",
          "properties": { "query": { "type": "string" } },
          "required": ["query"]
        }
      } }
    },
    "responses": { "200": { "description": "OK" } },
    "security": [ { "oauth2": ["query"] } ]
  }
}

You did not write either of these. They are produced from the brain and served by KBrain, and because they are generated from the same source the assistant calls, they stay accurate as the brain changes.

Why this matters

• No server to operate. The endpoint is hosted, so there is no deploy step and nothing to keep online.
• Documentation that cannot drift. The schema is generated from the brain the assistant queries, so it matches what the tool actually does.
• Portable by default. The same endpoint works in Claude, ChatGPT, and any MCP-compatible client. You build the knowledge once.
• Secure and read-only. OAuth is wired for you, and the tools only retrieve knowledge, they never modify your account or data.

The practical takeaway

MCP API documentation is a contract, not a document, and hand-writing and hosting that contract is the slow part of shipping a knowledge tool. KBrain generates it from your brain and serves it from an endpoint it keeps online, so connecting real knowledge to an assistant takes one click instead of a backend project.