> ## Documentation Index
> Fetch the complete documentation index at: https://docs.peeve.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Artifact reference

> The exact structure of each generated file.

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.

```text theme={null}
# Example Corp

> Verified, machine-readable capability map for AI agents, generated from Example Corp's product Brain. Each capability is something an agent can reliably invoke; routes are where they live.

## Capabilities

- [invite_teammate](/settings/team) — Invite a teammate to the workspace (write · confirmation required)
- [view_invoices](/settings/billing) — See past invoices and their status (read)
- [cancel_subscription](/settings/billing) — Cancel the subscription (destructive · confirmation required)

## Routes

- /settings/team — Team: manage members and invitations
- /settings/billing — Billing: plan, invoices and payment method
```

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:

```text theme={null}
# Example Corp

> Verified, machine-readable capability map for AI agents, generated from Example Corp's product Brain. Each capability is something an agent can reliably invoke; routes are where they live.

_No verified capabilities yet._
```

## `AGENTS.md`

`text/markdown; charset=utf-8`

An operating guide. The same capabilities, plus explicit ground rules.

```markdown theme={null}
# Example Corp — agent guide

This file is generated from the verified product Brain. It lists what an agent can do here and the guardrails on each action. Only agent-safe, verified capabilities are included.

## Ground rules
- Verify every capability against the live page before acting; the page wins on any conflict.
- Actions marked **confirmation required** must be confirmed with the user before execution.
- Never invoke a capability that isn't listed here.

## Capabilities

### invite_teammate
Invite a teammate to the workspace
- Location: `/settings/team`
- Permission: write · confirmation required

### view_invoices
See past invoices and their status
- Location: `/settings/billing`
- Permission: read
```

The ground rules are fixed text, present in every workspace's file.

## `server-card.json`

`application/json; charset=utf-8`

```json theme={null}
{
  "schema_version": "0.1",
  "name": "Example Corp",
  "description": "Agent-accessible capabilities for Example Corp, generated from its verified product Brain.",
  "url": "https://app.example.com",
  "provider": { "name": "Peeve" },
  "capabilities_count": 12,
  "routes_count": 34,
  "generated_at": "2026-08-17T10:04:00.000Z",
  "tools": [
    {
      "name": "invite_teammate",
      "description": "Invite a teammate to the workspace",
      "confirmation_required": true
    },
    {
      "name": "view_invoices",
      "description": "See past invoices and their status",
      "confirmation_required": false
    }
  ]
}
```

`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](/mcp/workspace-endpoint), plus a `_meta` block.

```json theme={null}
{
  "schema_version": "2024-11-05",
  "server": {
    "name": "Example Corp",
    "url": "https://app.example.com"
  },
  "tools": [
    {
      "name": "invite_teammate",
      "description": "Invite a teammate to the workspace",
      "inputSchema": {
        "type": "object",
        "properties": { "email": { "type": "string" } },
        "required": ["email"]
      },
      "annotations": {
        "title": "invite_teammate",
        "destructiveHint": false,
        "confirmationRequired": true,
        "readOnlyHint": false
      },
      "_meta": {
        "deep_link": "/settings/team",
        "route_path": ["Settings", "Team"]
      }
    }
  ]
}
```

<Note>
  `mcp.json` **describes** the tools; it is not an endpoint. To actually list and
  call them, use [the MCP server](/mcp/workspace-endpoint). The two are
  generated from the same projection, so they never disagree.
</Note>

### 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

| Field                  | Meaning                                                              |
| ---------------------- | -------------------------------------------------------------------- |
| `title`                | The capability key.                                                  |
| `readOnlyHint`         | True when the permission class is `read` and it is not destructive.  |
| `confirmationRequired` | True for a confirm-required write, or anything destructive.          |
| `destructiveHint`      | True when the capability destroys or irreversibly changes something. |

<Warning>
  These annotations describe the capability in your product. They do not mean an
  agent can execute it through Peeve — [`tools/call` returns guidance
  only](/mcp/overview).
</Warning>