Assess business transformation readiness

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

With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses the non-destructive default, the save=true side-effect, the null-exclusion behavior, why 'no risk' is not confused with 'not looked at', risk-factor handling with update_engagement JSON, and per-factor source/confidence attribution. This is exemplary transparency.

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 front-loaded with purpose and outputs, then moves through risk handling, null semantics, attribution, and persistence. It is longer because it is bilingual, but both language versions earn their place by conveying dense behavioral rules efficiently. Only minor redundancy with schema descriptions prevents a 5.

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, lack of output schema, and absence of annotations, the description covers the return values, the recommendation logic, the risk-JSON integration, the null semantics, the source/confidence options, and the save behavior. An agent can correctly invoke and interpret results from this description alone.

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 100%, so the baseline is 3. The description adds genuine cross-parameter meaning beyond the schema: recommendations depend on score band, gap width, and note content, not just factor name, and null current values interact with verdict exclusion. This meaningfully exceeds what the schema alone provides.

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 names a specific activity ('assess transformation readiness') and a concrete result set: bar table, overall verdict, per-factor reading with next move. It is clearly distinct from generic assessment tools, but it does not explicitly differentiate itself from the similarly named sibling 'assess_maturity' or from 'gap_analysis', so it falls just short of full sibling differentiation.

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 gives strong operational guidance for calling the tool, such as passing null for undetermined factors and setting save=true to persist, but it never states when to choose this tool over alternatives like assess_maturity or gap_analysis. Usage is implied by the subject matter, not explicitly scoped with exclusions or sibling trade-offs.

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