Skip to main content
Glama
Sign In
po4erk91

Thread Keeper

by po4erk91
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

curator_report_write

Idempotent

Atomically writes a Curator report to the configured report directory, using safe pass and batch IDs so sandboxed CLI agents can persist plans and verification results without filesystem access.

Instructions

Atomically write one Curator report inside the configured report dir.

This narrow tool is the cross-CLI alternative to direct filesystem Write: Codex workspace sandboxes cannot write ~/.threadkeeper/curator when the project is elsewhere. pass_id is filename-safe and cannot select an arbitrary path. A bounded multi-child pass supplies batch_index and batch_total so children cannot overwrite each other's reports. Repeated calls replace the same pass/batch report so the Curator can persist its plan before mutation and then add actual validation/rollback results. Only a parent-authorized spawned Curator carrying the matching pass ID may write a report; the final content hash is recorded for the report applier. The verifier passes phase='verify' and writes its own VERIFY-* report; only a child launched in the verify phase may do so.

Input Schema

NameRequiredDescriptionDefault
phaseNo
contentNo
pass_idNo
batch_indexNo
batch_totalNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.21.0
    • addedInput schema / properties / content / default
      Added value: +""
    • addedInput schema / properties / pass_id / default
      Added value: +""
    • addedInput schema / properties / phase
      Added value: +{
+  "default": "",
+  "title": "Phase",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "pass_id",
-  "content"
-]
  2. Addedv0.17.0

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover readOnly/idempotent/destructive; the description goes well beyond them, disclosing atomicity, that pass_id is filename-safe and cannot escape the report dir, that batch_index/batch_total prevent sibling overwrites, that repeated calls replace the same pass/batch report, the authorization requirement, and that a content hash is recorded for the applier.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, and each following sentence adds a distinct constraint rather than restating. It is somewhat long and dense with backticked identifiers, but the density is justified by the authorization and batching model it must convey.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with an output schema, five required-less parameters, and an unusual authorization model, the description covers the key operational facts an agent needs: destination scope, safety of pass_id, batch coordination, phase gating, and replacement semantics. Minor gaps remain around the content parameter and what the write returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load and mostly does: it explains pass_id (filename-safe, no arbitrary paths), batch_index/batch_total (multi-child disambiguation), and phase='verify' with its VERIFY-* report. Only 'content' is left implicit, described indirectly through the plan-then-results persistence use case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Atomically write one Curator report inside the configured report dir') and frames the tool as the cross-CLI alternative to a direct filesystem Write. It is distinct from most siblings, though it never explicitly names the close sibling curator_research_write, leaving that boundary for the agent to infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use context: Codex workspace sandboxes cannot write ~/.threadkeeper/curator when the project is elsewhere, so this tool is the substitute. It also states the gating conditions (only a parent-authorized spawned Curator with matching pass ID, verifier only in the verify phase), but does not contrast with curator_research_write or curator_restore.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools