marrow_evaluate_completion_contract

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the outcome space and that missing proof fields are returned, which is useful. However, it does not mention whether the tool has side effects, requires specific permissions, or how it processes the evidence object. The behavior is partially disclosed but not fully comprehensive.

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 two concise sentences with no redundancy. It front-loads the purpose and then lists the possible outputs, making it easy for an agent to quickly understand the tool's core function.

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?

There is no output schema, so the description must explain return values. It lists the four statuses and mentions missing proof fields, but does not detail the structure of the missing_proof object or how risk_level/evidence affect the result. Given the tool's moderate complexity, more detail would improve completeness.

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?

All four parameters have full descriptions in the schema (100% coverage), so the description adds no additional semantic value beyond what is already provided. The baseline 3 applies because the schema does the heavy lifting; the description only implicitly relates to evidence via 'missing proof fields'.

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 clearly states the tool's function: evaluating whether an agent has enough proof to mark work complete. It enumerates the exact return statuses (complete, missing_proof, review_required, blocked) and mentions 'missing proof fields', distinguishing it from sibling tools focused on memory or key management.

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 implies usage when deciding if work is complete, providing clear context. However, it does not explicitly state when not to use it or mention alternatives like marrow_completion_contracts. It gives enough context to infer the primary use case but lacks explicit exclusions.

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