bvandeusenandClaude Fable 5
64bfa5725f
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 7s
CI & Build / integration (push) Successful in 25s
CI & Build / TypeScript typecheck (push) Successful in 33s
CI & Build / Python tests (push) Successful in 1m3s
CI & Build / Build & push image (push) Successful in 20s
`retrieval_logs` was write-only. `record_retrieval` inserted rows and nothing in the tree ever selected from them: the only `select()` over RetrievalLog lived in a test. So #1038's gate — "build the reranker once telemetry shows precision is the bottleneck" — was unsatisfiable by construction, and the one real tuning decision on record (the 0.68 write-path threshold, #2223) had to be reached by hand-probing the live instance with eight payloads. This adds the half that was missing. `retrieval_summary(user_id, days=30)` returns two aggregates side by side, each read from the table built for it — NOT a join. NoteUsageEvent's docstring is explicit that the two are complements ("RetrievalLog tunes the threshold, this tunes the corpus") and that RetrievalLog's JSONB `result_ids` cannot be indexed at the per-note grain, so correlating through it would be both slower and less honest than reading each source directly. That corrects the approach sketched on the task. - `sources`, per surface: calls, zero_result_calls, cleared_threshold (how often the best hit beat the threshold in force for THAT call), the top_score spread as p10/p50/p90/min/max, avg_result_count, p90 duration. Zero-result calls are counted apart from low-scoring ones — they are a different failure and averaging them together would hide both. - `usage`, from note_usage_events: ranked surfacings, ambient surfacings, and pulls split into `pulled_by_agent` / `pulled_by_human`. That split is not decoration. NoteUsageEvent's own comment says the mcp_/rest_ prefix is load-bearing and names #1038 while saying so: "is this dead weight?" is answered by any pull, "was that injected line useful?" only by an agent pull. `pull_through` exists to answer the second, so it counts agent pulls over ranked surfacings; both halves ship so the first stays answerable. Two things the code made me get right rather than guess: - Distinct-note counts get their own queries. `count(distinct note_id)` per (event, source) group cannot be summed across groups — a note surfaced by two sources is one distinct note and would be counted twice. A wrong number labelled "distinct" is worse than no number. - No CASE in the GROUP BY. #2663 is the bug where a second case() rendered its own expanding bind names, Postgres rejected the query, a broad except swallowed it, and every counter read zero in production while mocked tests passed. Grouping on raw `source` and classifying in Python cannot fail that way. For the same reason the readout distinguishes `read_failed` from an empty window, and its tests are integration against real Postgres — percentile_cont ... WITHIN GROUP only proves it parses against a database. Exposed as the `retrieval_telemetry` MCP tool, added to `_READ_ONLY_TOOLS`: it mutates nothing, but its name carries no read prefix, so the completeness test cannot derive it and it would otherwise have failed closed for read-only keys in silence — the same reason `enter_project` is spelled out there. Docs updated to name both exceptions rather than leave the rule looking derivable. Scoped to the caller's own telemetry: a retrieval log records what one user's agent asked for, query text included, and is not a shared record kind — the owner filter is the whole access rule, not a shortcut past access.py. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
101 lines
4.2 KiB
Markdown
101 lines
4.2 KiB
Markdown
# API Keys and Scribe MCP
|
|
|
|
## API Keys
|
|
|
|
API keys let external tools access your Fable data without a browser session. Each key is scoped to a single user — it can only access data that user owns or has been shared with them.
|
|
|
|
### Scopes
|
|
|
|
| Scope | Permissions |
|
|
|-------|-------------|
|
|
| `read` | GET endpoints only — list, search, fetch content |
|
|
| `write` | Full read + create, update, delete |
|
|
|
|
Admin-level operations (log access, user management) require a `write`-scoped key from an admin account.
|
|
|
|
### Creating a Key
|
|
|
|
1. Go to **Settings → API Keys**
|
|
2. Enter a name (e.g. "Claude MCP", "Home Server")
|
|
3. Choose scope
|
|
4. Click **Generate Key**
|
|
5. Copy the key immediately — it is shown only once (the token is `fmcp_`-prefixed)
|
|
|
|
Paste the key into the `Authorization: Bearer <key>` header of your MCP client
|
|
config (see **Scribe MCP Server** below).
|
|
|
|
### Revoking a Key
|
|
|
|
Click **Revoke** next to the key in the API Keys table and confirm. Revoked keys are deleted immediately.
|
|
|
|
---
|
|
|
|
## Scribe MCP Server
|
|
|
|
Scribe exposes itself as a set of MCP tools that Claude (and other MCP clients)
|
|
can use to read and write your notes, tasks, projects, rulebooks, and more. The
|
|
server is **built into the app** — it is mounted as a streamable-HTTP endpoint
|
|
at **`/mcp`** on the running Scribe instance (`src/scribe/mcp/server.py`). There
|
|
is nothing to install: no wheel, no separate package, no CLI. You connect a
|
|
client straight to the URL with a Bearer token.
|
|
|
|
### Authentication
|
|
|
|
Authenticate with an API key generated from **Settings → API Keys** (see above),
|
|
sent as `Authorization: Bearer fmcp_<key>`. A `read`-scoped key may call only the
|
|
read tools (`get_*`, `list_*`, `search`, `enter_project`, `retrieval_telemetry`);
|
|
any write/delete tool is rejected with `403`. The allow-list is explicit rather
|
|
than derived from the name — see `_READ_ONLY_TOOLS`, which is why the two reads
|
|
without a read-shaped name are spelled out here. A `write`-scoped key may call everything.
|
|
|
|
### Claude Code (Project-scoped)
|
|
|
|
Add a `.mcp.json` at the project root. The server `type` is `http` and the URL is
|
|
your instance's `/mcp` endpoint:
|
|
|
|
```json
|
|
{
|
|
"mcpServers": {
|
|
"scribe": {
|
|
"type": "http",
|
|
"url": "https://your-scribe-instance.example.com/mcp",
|
|
"headers": {
|
|
"Authorization": "Bearer fmcp_your-api-key"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
Note: `.mcp.json` contains an API key and should be added to `.gitignore`.
|
|
|
|
### Claude Code (Global)
|
|
|
|
The same `mcpServers` block can live in `~/.claude.json` to make the server
|
|
available across all projects. A project-scoped `.mcp.json` takes precedence over
|
|
the global entry when both define the same server name — useful for pointing a
|
|
specific project at a dev instance or an admin key.
|
|
|
|
### Available Tools
|
|
|
|
The tool surface is large (~70 tools) and evolves with the app, so the live
|
|
registration in **`src/scribe/mcp/tools/`** is the source of truth rather than a
|
|
table here. The tools are grouped by family:
|
|
|
|
| Family | Examples | Purpose |
|
|
|--------|----------|---------|
|
|
| Notes | `create_note`, `get_note`, `update_note`, `delete_note`, `list_notes` | Free-form knowledge |
|
|
| Tasks | `create_task`, `update_task`, `add_task_log`, `start_planning` | Actionable work + plans |
|
|
| Projects / Milestones | `enter_project`, `get_project`, `create_milestone`, … | Containers and outcomes |
|
|
| Search / Recall | `search`, `get_recent`, `list_tags`, `retrieval_telemetry` | Semantic + structured recall, and the readout its thresholds are tuned from |
|
|
| Systems | `create_system`, `list_systems`, `list_system_records` | Reusable per-project subsystems/areas |
|
|
| Rulebooks | `list_always_on_rules`, `list_rules`, `create_rule`, `create_project_rule`, `subscribe_project_to_rulebook`, … | Engineering/workflow rules |
|
|
| Processes | `list_processes`, `get_process`, `create_process` | Saved prompts/workflows |
|
|
| Trash | `list_trash`, `restore`, `purge_trash` | Recoverable deletes |
|
|
| Admin | `get_app_logs` (write/admin key) | Diagnostics |
|
|
|
|
Server-level usage guidance — when to reach for each entity, the
|
|
recall-before-acting reflex, and the rulebook conventions — is delivered to the
|
|
client automatically via the MCP server's `instructions` block (defined in
|
|
`src/scribe/mcp/server.py`).
|