Runs SQLite store maintenance across existing harness roots by truncating WAL files and restoring private 0600 permissions; skips roots without stores and never creates new ones.
Run sqlite store maintenance on every existing harness store root: truncate the WAL via wal_checkpoint(TRUNCATE) and re-assert private 0600 file modes. Roots without a store are skipped, never created.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is largely covered. The description adds real value by disclosing the exact side effects (WAL checkpoint truncation, chmod to 0600) and the non-creation guarantee, but says nothing about permissions required, failure handling on partially-maintained roots, or what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler: the operation and its mechanism come first, and the skip/never-create boundary follows. Every clause carries information an agent could not get from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema maintenance tool, the description covers what is mutated, the safety boundary around absent stores, and idempotency consistent with the annotation. The only real gap is the absence of any statement about the return value or how failures on individual roots are surfaced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics to explain and the description correctly avoids inventing any. The stated behavior implies the scope is derived from ambient harness state rather than input, which is implicit rather than stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Run sqlite store maintenance') and enumerates the concrete operations: WAL truncation via wal_checkpoint(TRUNCATE) and re-asserting 0600 modes. It is distinguishable from sibling mutators like state_write or state_prune, though it never explicitly names an alternative to route against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Useful scope constraints are given: it acts on 'every existing harness store root' and skips roots without a store, never creating them. However, there is no guidance on when to prefer this over state_doctor or state_prune, which are the closest siblings, so the when-to-use decision is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.