hai_get_contract

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It states that the result is exact and canonical rather than summarized, but it does not disclose whether the operation is read-only, idempotent, or what happens when the session lease is invalid or expired. The agent is left to infer important error and authorization semantics.

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 a single, well-structured sentence with no filler. The most important information—what is returned and for which input—is front-loaded, and the contrast with a summary is placed prominently.

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 tool is simple: one required parameter, an output schema exists, and there are no nested objects. The description supplies the essential purpose and the prerequisite of a valid session lease, while the output schema covers return-value details. The main omissions relate to usage alternatives and invalid-lease behavior, which are captured in other dimensions.

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 0% schema description coverage, the description must compensate. It adds the notion of a 'valid session lease', which helps the agent interpret session_id as a lease identifier that must be valid. However, it does not explain the expected format, how validity is determined, or how to obtain such a lease, so the compensation is partial.

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 action ('Return') and the exact resource ('exact canonical mission contract'), and it distinguishes the result from a summary. It also scopes the call to 'a valid session lease', making the tool's purpose easy to identify among the sibling tools.

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 implicitly tells the agent that a valid session lease is required and warns that the result is not a summary. However, it does not explicitly name alternatives or state when to use another tool such as hai_status, hai_get_next_step, or hai_read_artifacts instead. The usage context is inferable but not fully explicit.

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