Your product's knowledge, in the form an AI agent can actually use.

cuppy hosts documentation hubs that coding agents read over MCP: one first document, one named next read, and facts that are versioned, layered and measured by what agents actually used.

cuppy documents and never acts. It serves documents and renders the request an operation would make; it runs nothing, and it holds no credential to your systems. The agent does the work, with its own hands.

Connect your client

Pick the one you use. Each opens its own connection details: the endpoint to paste, the vendor’s own install link or command where there is one, and the steps that vendor documents.

AI Commander
manual

The agent console this platform is built with: register the endpoint and every session can read the hub.
MCP endpoint
```
https://cuppy.io/mcp
```
claude.ai
manual

Add the hub as a custom connector and every chat can read it.
MCP endpoint
```
https://cuppy.io/mcp
```
ChatGPT
manual

Register the endpoint once as an MCP server in settings.
MCP endpoint
```
https://cuppy.io/mcp
```
Claude Code
one command

One line in your project and the hub answers in your terminal.
MCP endpoint
```
https://cuppy.io/mcp
```
The vendor’s own command
```
claude mcp add --transport http cuppy https://cuppy.io/mcp
```
Cursor
one click

One click: the install link pre-fills the server for you.
MCP endpoint
```
https://cuppy.io/mcp
```
Add cuppy to Cursor
VS Code (Copilot)
one click

One click through the editor’s own MCP install handler.
MCP endpoint
```
https://cuppy.io/mcp
```
Add cuppy to VS Code
Windsurf
manual

Cascade reads the hub once the endpoint is in its MCP config.
MCP endpoint
```
https://cuppy.io/mcp
```
Gemini CLI
one command

One command, then the hub is a tool source in every session.
MCP endpoint
```
https://cuppy.io/mcp
```
The vendor’s own command
```
gemini mcp add --transport http cuppy https://cuppy.io/mcp
```
Codex CLI
one command

Add the endpoint as a remote server in one command.
MCP endpoint
```
https://cuppy.io/mcp
```
The vendor’s own command
```
codex mcp add cuppy --url https://cuppy.io/mcp
```
Zed
manual

A context server in settings; Zed handles the sign-in itself.
MCP endpoint
```
https://cuppy.io/mcp
```

Every client, with the steps

What a hub is

Not a wiki and not a search box. A hub has a fixed spine, documents that declare what they are, and a reading order an agent can follow without being told twice.

One first read, then a named next read

Every hub opens at _boot/START.md under a token budget. Each hop names the smallest next document instead of returning everything.

Layers fill, never fork

A customer layer adds its own guides, overrides and examples over a vendor hub. It inherits the rest live, and nothing is copied to be kept up to date by hand.

Documents declare what they are

A role and a shape in front matter — reference, guide, operation, interface, error and the rest — so a client knows what it is holding before it reads the body.

Documents, never actions

An operation document renders the request to make. Nothing here executes it, and no credential of yours is stored to make that possible.

One tool surface, every endpoint

The same small set of tools answers on every hub’s endpoint, so an agent that learned one hub has learned them all.

Measured by what was used

Every serve is recorded against the document that answered. What agents actually read is what ranks next, so a hub gets better from being used.

How an agent gets to work

Step 1

Point the client at a hub

One HTTP MCP URL per hub. No key to paste, no header to set.

Step 2

Read a public hub with no credential

A public hub answers an MCP client with no sign-in, no key and no header, so there is nothing to set up. For a private hub, or to search as yourself, add the signed-in address /mcp/_me instead: the client is sent to this site to sign in once, holds its own token afterwards, and no page here will ever show you a key.

Step 3

Read the boot document, then search

_hello for where it is, the boot document for how this hub works, then search and get for the facts the task needs.

Managed code releases

Autonomous Release Testing and Learning Loops

For dev and test agentic test looping: autonomous development cycles, and CI/CD for an MCP endpoint. A release publishes an artifact and a test prompt. A client agent picks it up, identifies itself, runs the prompt against the live MCP surface and reports what it found — and the report counts only when the server’s own log carries the same run. A report with no matching server-side record is void.

cuppy publishes the artifact and the prompt and matches the report against its own log. The agent runs the prompt, with its own hands: nothing here executes your release.

release artifact
  └─ test prompt published
       └─ client agent self-identifies
            └─ runs against the live MCP surface
                 └─ reports what it found
                      └─ matched on the server's own log

This platform's own documentation

See all hubs

cuppy

cuppy.io

this platform's own hub

How to use cuppy: the platform's own documentation hub — what a hub is, how an agent reads one, what the tools do and how to connect.

https://cuppy.io/mcp

Every other hub this deployment serves — each product’s own documentation, with its own endpoint — is in the directory.