bvandeusenandClaude Fable 5
64bfa5725f
`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>
4.2 KiB
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
- Go to Settings → API Keys
- Enter a name (e.g. "Claude MCP", "Home Server")
- Choose scope
- Click Generate Key
- 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:
{
"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).