Skip to main content
All four are generated from the same projection. Examples below use a fictional workspace.

llms.txt

text/plain; charset=utf-8 An H1, a summary blockquote, then a capability list and a route list.
Each capability is a link when it has a deep link or a route, and carries its permission class in parentheses. The permission labels are read, write, write · confirmation required, and destructive · confirmation required. With nothing verified yet:

AGENTS.md

text/markdown; charset=utf-8 An operating guide. The same capabilities, plus explicit ground rules.
The ground rules are fixed text, present in every workspace’s file.

server-card.json

application/json; charset=utf-8
url is your workspace’s domain. If you have not set one, it falls back to {slug}.peeve.ai, which is another reason to set your domain early. confirmation_required is true when the capability is a confirm-required write or destructive.

mcp.json

application/json; charset=utf-8 MCP tool definitions — the same shape tools/list returns from the live MCP server, plus a _meta block.
mcp.json describes the tools; it is not an endpoint. To actually list and call them, use the MCP server. The two are generated from the same projection, so they never disagree.

Input schemas

inputSchema is derived from the capability’s recorded parameters. Peeve accepts either shape from the map — an array of { name, type, required } objects, or an object keyed by parameter name — and normalises both to JSON Schema. Parameters with no stated type default to string. A capability with no parameters gets { "type": "object", "properties": {} }.

Annotations

These annotations describe the capability in your product. They do not mean an agent can execute it through Peeve — tools/call returns guidance only.