curator_report_write

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

Beyond the annotations, the description discloses atomicity, path-safety guarantees for pass_id, batch semantics to prevent child overwrites, replacement behavior on repeated calls, and recording of the final content hash. None of this contradicts readOnlyHint=false, idempotentHint=true, or destructiveHint=false.

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?

The purpose is front-loaded in a clear first sentence, and every sentence adds relevant operational context. The description is dense with domain-specific terminology like 'bounded multi-child pass' and 'parent-authorized spawned Curator,' which is appropriate for the audience but prevents it from being maximally crisp.

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 specialized write tool with an output schema and detailed annotations, the description covers purpose, alternative, authorization, safety constraints, batch behavior, idempotent replacement, and downstream hash recording. An agent has enough information to call it correctly without needing the return format explained.

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?

With schema description coverage at 0%, the description compensates by explaining pass_id is filename-safe, batch_index/batch_total coordinate multi-child writes, and content is the report being persisted. It stops short of specifying the exact expected content format or the valid range/relationship of batch_index to batch_total, so it is strong but not exhaustive.

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 first sentence states a specific action ('Atomically write one Curator report') and the destination ('inside the configured report dir'). The follow-up frames it as a narrow alternative to direct filesystem Write, which separates it from broader curator lifecycle tools like curator_run and curator_review.

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?

It gives an explicit selection condition: use this tool instead of filesystem Write when the Codex sandbox cannot write ~/.threadkeeper/curator because the project is elsewhere. It also documents the authorization gate (parent-authorized spawned Curator with matching pass ID) and the intended write/replace workflow.

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