seal_criteria

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns a digest that commits to criteria without revealing them, and it enforces immutability ('cannot be adjusted afterward'). While it does not cover failure modes or required permissions, it provides substantial behavioral context for a sealing operation.

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 sentences, efficient and front-loaded. The first sentence states the core action and purpose, the second sentence explains the return value and timing. Every sentence earns its place with no redundancy.

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 explains the core concept and timing well, but is incomplete in crucial areas. It does not explain the return digest format or the parameters, especially the nested spec object and optional note/out_path. For a tool with no annotations, output schema, or parameter descriptions, this leaves the agent with insufficient information for correct invocation.

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 description provides zero information about the parameters. The schema lists three parameters (spec, note, out_path) with no descriptions, and the description mentions none of them. With 0% schema description coverage, the description fails to compensate, leaving the agent without guidance on what to pass for each parameter.

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 action ('Seal an acceptance specification') and its specific purpose (to prevent adjustment after measuring). It also distinguishes itself from sibling tools by emphasizing the pre-measurement timing and the commitment aspect, which is unique among the listed siblings focused on verification and explanation.

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 provides explicit timing guidance: 'Call this before running an experiment, not after.' This clearly indicates when to use the tool and when not to. However, it does not explicitly mention alternative tools or provide comparative use cases, which would elevate it to a 5.

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