decision_card_infer_status

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

No annotations are provided, so the description carries full behavioral burden. It discloses the complete mapping rules from rubric results to status and states that an unsupported result returns an error, never an approval. It does not state whether the operation is read-only or has side effects, but the term 'preview' implies non-persistence.

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 tightly written sentences that are front-loaded with the core action, followed by the detailed mapping logic and an edge-case rule. Every sentence contributes essential information with no wasted words.

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?

Given the tool's complexity (inference from an enum-based rubric), no output schema, and no annotations, the description provides the critical mapping rules and error behavior. It is nearly complete, though it omits details on the input structure (e.g., the 'id' field) and the exact return shape beyond 'decision.status'.

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 explains the semantics of the 'result' enum values in terms of their effect on the inferred status, which adds partial value. However, it never mentions the required 'id' field or the array-of-objects structure of the 'rubric' parameter, leaving a significant gap.

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 uses specific verbs ('Validate', 'infer') and names the resource ('each rubric row', 'decision.status'), making the core purpose clear. However, it does not explicitly differentiate itself from the sibling 'decision_card_validate', leaving some ambiguity about when this inference tool is preferred over the validation tool.

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 by describing the inference logic, but it provides no explicit when-to-use guidance or alternatives. With a close sibling ('decision_card_validate'), an agent must infer that this tool is for computing a preview status from raw rubric rows rather than validating a card structure.

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