close_partition

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

No annotations are provided, so the description carries the full burden of disclosing side effects. It does so well: it explains the erasure behavior for context partitions, the retention behavior for process/agent partitions, the exception when disposition='erased', and the recording of a lifecycle entry in the action ledger. This is strong behavioral context, though it stops short of covering additional consequences like reversibility or error cases.

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 description is three tight sentences with no filler. The core action is front-loaded, followed by the key behavioral nuance and the ledger side effect. Every sentence earns its place.

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?

The description covers the main side effects and the disposition semantics, but with no output schema, no annotations, and no explanation of name/actor parameters, it is not fully complete. An agent could invoke it correctly, but important details about required inputs and expected response are absent.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics only for the disposition parameter, clarifying when records are erased vs kept. The name and actor parameters are left entirely to their labels, so an agent gets little guidance about what values they should carry or how they affect the close operation.

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 opens with a specific verb and resource ('Close a partition') and adds the triggering condition ('when its process ends'), which clearly defines what the tool does. The additional detail about context vs process/agent partitions further distinguishes this from open_partition and sweep_partitions without needing to name them.

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?

The description gives clear usage context: close a partition when its process ends. It does not explicitly name alternative tools or exclusion conditions, but the 'when its process ends' framing provides enough situational guidance for an agent to know when this tool applies.

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