fusion_inspect

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value by enumerating what the response contains, including diagnostic content (timeline problems, invalid bodies) and the unit for size, and by noting what detail='full' expands. It stops short of noting cost or performance implications of the fuller mode.

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?

Two tight sentences: the default behavior and its returns come first, the opt-in expansion second. No filler, and every clause conveys distinct information.

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?

With no output schema, the description must convey return content, which it does at a useful granularity for both the default and full modes. The main gap is the lack of sibling disambiguation, which matters given nine similarly named fusion_* tools.

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 coverage is 0% and the single parameter has no description, so the description carries the burden — and it does explain that detail='full' adds per-body boxes and user parameters, versus the default summary payload. The full set of accepted values (the schema shows only a bare string with default 'summary') is not enumerated, leaving ambiguity about valid alternatives to 'full'.

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?

States a concrete verb-resource pair ('compact state of the active design') and enumerates the payload (counts, size, volume, timeline problems, invalid bodies). It is clear but does not differentiate itself from similar read-oriented siblings like fusion_status or fusion_check, so an agent can't tell them apart from the description alone.

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 second sentence implies a usage choice between default summary and detail='full', which is genuinely useful routing info. However there is no explicit when-to-use or when-not-to-use guidance relative to fusion_status, fusion_check, or fusion_look, so selection between siblings is left to inference.

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