governance_assess_plan

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. 'Assess' hints at a read-only analysis, but the description does not state whether the tool mutates state, requires authentication, or has side effects. This is a significant gap for an unannotated tool.

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 one compact, front-loaded sentence with no filler. It is easy to read and the criteria list is immediately visible, though its brevity comes at the cost of missing critical usage and parameter details.

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?

While the presence of an output schema reduces the need to explain return values, the tool still has an opaque nested parameter and many similar siblings. The description is too thin to be complete—it does not clarify the operation parameter shape, the expected input format, or when this assessment tool should be selected over alternatives.

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 single 'operation' parameter has 0% schema description coverage and is an open object with additionalProperties: true. The description does not explain what fields the operation object should contain, how the plan or evidence is structured, or how the five assessment dimensions map to inputs. The description adds no meaningful parameter semantics.

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 the verb 'assess' and names five specific evaluation dimensions (necessity, bounded work, elapsed time, difficulty, cost evidence), giving a clear sense of what the tool does. However, it does not explicitly say it assesses a 'plan' or differentiate itself from sibling governance assessment tools like governance_evaluate_operation or governance_evaluate_gate.

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 no guidance on when to use this tool versus alternatives. It lists assessment criteria but gives no context, prerequisites, or exclusions, leaving the agent to guess when this tool is appropriate.

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