Sovereign Agent Logbook
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOGBOOK_PATH | No | Path to the append-only, hash-chained logbook file where events are written (for example /var/lib/logbook/agent.jsonl). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Tamper-evident logbook for AI agents. Call log_event BEFORE every action with side effects (writes, sends, payments, deletions) and AFTER it completes to record the outcome. Never skip logging because an action seems minor. Secrets in arguments are masked automatically.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| log_eventA | Record one agent action in the logbook. Who: agent_id (your agent's stable name) and model (e.g. "mistral-small-4"). What: action (the tool or operation) and arguments (secrets are masked). Why: reason — one plain sentence. Approval: "human" with approved_by, "auto" with approval_rule, or "none". Outcome: "pending" when logging before the action; log again with "success", "error" or "escalated" after it. Returns the stored record including its seq and hash. |
| verify_logbookA | Check the whole logbook's hash chain. Returns ok, event count and any problems in plain English. |
| recent_eventsC | Return the most recent events (default 20) for a quick look. |
| export_logbookB | Export the full logbook as JSON or CSV text that an auditor can read without this tool. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| about | Version and configuration of this logbook server. |
TDQS
Scored across 4 tools
Each tool maps to a distinct operation on the logbook: log_event writes, recent_events reads a quick tail, verify_logbook checks hash-chain integrity, and export_logbook produces an auditor-facing dump. The write/read/verify/export split is unambiguous, and the only mild adjacency (recent_events vs export_logbook) is clearly differentiated by scope and format.
All names use consistent snake_case and are built around the shared noun 'logbook'/'event'. Three tools follow a verb_noun pattern (log_event, verify_logbook, export_logbook), but recent_events deviates into an adjective_noun form, a minor inconsistency in an otherwise predictable scheme.
Four tools is compact but well-matched to an append-only audit log with verification and export needs. Each tool earns its place: write, inspect, verify, and hand off to a human auditor, with no redundant or filler operations.
The core lifecycle of an audit logbook (record, inspect, verify integrity, export) is covered, and outcome re-logging handles status transitions without a separate update tool. Minor gaps remain: recent_events caps at a small tail with no paging or filtering by agent, seq, or time range, so the only way to traverse full history is the export dump.