Connect to it
These docs are served over MCP at one address:
https://pithy.sh/mcpClaude Code:
claude mcp add --transport http pithy-docs https://pithy.sh/mcpA client that takes a JSON config — Claude Desktop, Cursor, and most others:
{
"mcpServers": {
"pithy-docs": {
"type": "http",
"url": "https://pithy.sh/mcp"
}
}
}VS Code uses the same fields under servers rather than mcpServers.
It is authenticated, and your client handles that. The endpoint is an OAuth protected resource: the first connection runs a discovery and authorization round trip, which every MCP client with remote-server support does on its own. You will approve it once in a browser. There is no key to paste and none to keep.
This is not the search on the website. The site’s public search covers posts and pages; the documentation and the reference are served here instead, which is why an agent pointed at the wrong one gets a marker saying so rather than the page it asked for.
Point it at the source, not at a summary
Driving the CLI from an agent is the other half of this, building with AI agents is the wider practice, and the two sets worth pointing at are the capability catalog and the reference.
The kit’s own documentation lives beside the code, and it is written to be read rather than skimmed — the command pages, the naming rules, the control-plane design, the language rules.
These docs are a rendering of the same material. Where the two disagree, the source is right.
The two things an agent gets wrong
1. It writes a doc comment’s intention as fact.
2. It invents a plausible API.
An agent that knows a hundred backends will confidently produce pithy adopt, or pithy secrets set, or a registerTemplate call.
None of those exist. The secret commands are create and update; there is no adopt; the email registry is closed and the reasons are on the page.
The catalog and the command list are the authority for what exists.
What to give it
**The **capability catalog — every capability, one line each, and what each composes with.
**The **CLI section — one page per command, each specified completely, and each held by a build gate to naming every key its --json payload emits.
**The **Reference section — bindings, tables, routes, error codes, request context. Facts in tables, with the source named.
**The **core concepts — because most wrong answers come from not knowing that a seam is present-and-inert rather than absent.
The rules an agent should be told once
Every table is pithy_<capability>_*. So is every error code’s domain, every audit action’s domain, every catalog key’s domain, and every migration namespace. One segment, five jobs.
Guards before validators, always.
A seam is present and inert, never absent — so c.var.emit(...) needs no conditional.
The entitlement resolver is the one seam whose default denies, because a missing audit write cannot grant access and a missing entitlement check can.
Never export a Durable Object class from a package entry point.
Model a failure as a code plus params, never a message alone.
What it can safely run
Every command takes --json, except pithy remove, which rejects it.
Sync, doctor, migrate and every provision are safe to repeat.
Stop at a supplied secret, at a routing-zone flag, and at production’s type-to-confirm phrase.
Ask it to check its own claims
The kit’s docs say when something does not exist, and those sentences are the useful ones: retention is not implemented, there is no generated catalog, Google exposes no opt-in count, Colyseus ships a better hidden-state primitive.
An agent that reproduces those is reading. One that omits them is guessing.