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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds valuable context beyond that: the return shape differs by query mode (member list with docs vs. class list), which the agent cannot infer from the schema. It does not mention result caps or how the 'limit' default of 60 interacts with output.

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 sentences, zero waste: behavior first, then the call-to-action sequencing constraint. Front-loaded and immediately actionable.

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?

For a two-parameter read-only lookup with no output schema, the description supplies the essential behavior and the when-to-use rule. Completeness is only slightly diminished by the undocumented 'limit' parameter and no hint of what happens when a query matches nothing.

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 carry parameter meaning, and it does for the required 'query': exact class name vs. keywords, each with a concrete example. The optional 'limit' parameter is never mentioned, leaving a real 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?

States a specific verb+resource ('look up the real Fusion API') and explains the two result modes: class members with docs, or matching classes. Clearly distinguishable from siblings like fusion_run or fusion_inspect, which execute and inspect the model rather than fetch API documentation.

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?

Gives an explicit usage rule: 'Use this before writing fusion_run code.' That names the sibling it complements and the condition under which to call it, which is exactly the routing information an agent needs.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that it returns pass/fail plus reasons, which matters since there is no output schema, but it says nothing about how tolerance affects the result or what the failure reasons look like.

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?

A single compact sentence that front-loads the validation scope and ends with the return contract. Every clause earns its place, with no filler.

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?

For a two-parameter read-only check with no output schema, the description covers scope and the pass/fail return shape. However, the undefined tolerance parameter and the absent guidance on navigating to sibling tools leave real gaps for correct invocation.

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 carry parameter meaning. It gestures at expected_size_in via 'optionally the overall X/Y/Z size in inches' but never mentions tolerance_in at all, leaving half the parameters with no explanation anywhere.

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 verb (validate) and enumerates the concrete checks: body validity, timeline health, body-to-body interference, and optional overall size. That is far more specific than siblings like fusion_status or fusion_inspect, though it never explicitly names which sibling covers overlapping ground.

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 word 'optionally' signals when the size check engages, implying expected_size_in is conditional. But there is no explicit guidance on when to call fusion_check versus fusion_status, fusion_inspect, or fusion_run, leaving the agent to infer from the enumerated checks.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that writes go to the local filesystem and never the cloud, but omits whether an existing file at the target path is overwritten, what happens if no design is active, and what is returned.

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 with zero waste; the core action and format list come first, and the local-only constraint follows as a qualifier. Nothing is padded or restated from the title.

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 and no annotations about return values, the description should say what the call yields (file path, success flag) and how `path` interacts with `format`. The format coverage is complete, but this mutation tool remains underspecified on the write target and result.

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 — and it partly does by enumerating the valid `format` values (step, stl, f3d, obj, 3mf, iges, sat) where the schema only offers a bare string with no enum. The `path` parameter is left completely unexplained: no indication whether it is a directory, a full filename, or what the empty default means.

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 specific verb (export), the exact resource (the active design), and enumerates all supported output formats. It is unambiguously distinct from every sibling (status, api, run, rollback, inspect, check, look, render, ui_command), none of which export geometry.

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?

Usage is only implied by the verb 'export the active design'; there is no explicit when-to-use or when-not guidance, and no sibling alternative is named. The one routing hint given — 'Local file only (never the cloud)' — is a scope constraint rather than a selection rule.

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

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.

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 by structured data, lowering the burden on the description. The description adds the roster of valid named views, which is genuinely useful operating context, but it says nothing about what happens when views is null, whether captures are synchronous, or how results are delivered.

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?

One tightly packed sentence with the action front-loaded and the valid values listed inline. Every word earns its place, including the view list, which doubles as parameter documentation.

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 should indicate what the caller receives — image bytes, base64, a file path, or a URL — and it is silent on this. For invocation itself it is adequate: view names are given and defaults for width/height come from the schema. The unresolved null-views behavior and return format are the notable gaps.

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 carry parameter meaning. It does supply the critical semantic — the accepted view names — which the schema does not enumerate at all. But it leaves width and height entirely unexplained (units, whether they matter when a view is not specified) and doesn't say whether views=null means all views or the current view.

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 states a specific verb ("Screenshot") and resource ("the active Fusion viewport") and enumerates the seven valid viewpoints, so an agent knows exactly what it produces. It doesn't explicitly contrast with fusion_render or fusion_export, which likely also produce visual output, so sibling differentiation is inferred rather than stated.

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?

Usage is implied by the enumerated named views — the agent can infer this is for quick visual inspection at standard orientations. However, there is no statement of when to prefer this over fusion_render or fusion_export, nor any prerequisites (e.g., an open active document).

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

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

Annotations declare readOnlyHint=false but destructiveHint=false, which is unusual for a non-mutating render; the description's 'render of the active design' supports the non-destructive read and adds that rendering is local and that quality drives duration. It does not say where the output goes (returned image vs. file on disk) or how long a high-quality render takes.

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?

A single front-loaded sentence with no filler; the quality range and its performance implication are packed into a parenthetical.

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 and no parameter documentation, the description should explain what a render call returns and what width/height control, but it is silent on both, leaving an agent unable to predict the result of the call.

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 carry parameter meaning, yet it only explains quality (range 25-100, higher is slower). Width and height are completely undocumented in both schema and description.

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 specific verb and resource: produces a photoreal render of the active design using a local renderer. It implicitly separates itself from file-oriented siblings like fusion_export, but never names an alternative to confirm the boundary.

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?

Use is implied (you want an image of the current design), and the quality/speed tradeoff hints at choosing settings, but there is no explicit when-to-use versus fusion_export, fusion_look, or fusion_inspect.

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

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

Annotations already declare destructiveHint=true, so the description's job is to add scope, and it does: it specifies exactly what is removed (every timeline item after the checkpoint), which is real context beyond the annotation. It stops short of saying the deletion is irreversible or whether confirmation is required.

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?

One sentence, front-loaded with the destructive verb and scope, with zero filler. Nothing could be cut without losing meaning.

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?

A single-required-param destructive mutation with no output schema needs a bit more: whether the checkpoint item itself survives, whether the operation is reversible, and what happens on a stale/unknown checkpoint are all unaddressed. Adequate but with clear gaps for a destructive tool.

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% — the schema only says 'integer' with title 'Checkpoint'. The description supplies the crucial semantic that the value must come from fusion_run, which is the single most important fact for calling this tool correctly.

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 specific verb ('delete') and resource ('every timeline item after checkpoint'), which is far more informative than the bare name fusion_rollback. It is distinguishable from siblings like fusion_run and fusion_status, though the word 'timeline' is not defined anywhere.

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 name and the parenthetical pointing at fusion_run imply the use case (undo work back to a known point), but there is no explicit when-to-use versus when-not, no mention of prerequisites such as an active session, and no alternative suggested.

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

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

Annotations declare destructiveHint=true and openWorldHint=false, but the description adds genuinely non-derivable behavior: the 90 s timeout, execution on the main thread, the whitelist of blocked operations (file deletion, network, cloud save), and that a rollback checkpoint is returned. It doesn't state what happens when the timeout fires or how errors surface, which keeps it from a 5.

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?

Three tight sentences with the constraint-heavy information (main thread, 90 s limit, blocked operations) front-loaded. It is dense with useful signal rather than padded, though the unexplained abbreviations (P3, VI, FO, IN) cost some readability.

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 correctly explains the return contract (set `result`, receive a checkpoint for fusion_rollback), and it covers the sandbox behavior an agent needs before executing arbitrary code. The main residual gap is `label` and error/timeout semantics.

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%, so the description must carry the load. It does well for `code`, documenting the predefined symbols (app, ui, design, adsk, P3, VI, FO, IN, coll, board) and the `result` output convention, but `label` is never mentioned, leaving one of two parameters completely undefined.

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 specific verb and resource ('Run Python inside Fusion's main thread') and adds the 90 s execution limit, which immediately scopes expectations. It partially differentiates from siblings by naming fusion_rollback as the consumer of its output, but doesn't distinguish itself from fusion_api or fusion_ui_command, which are the closest alternatives.

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?

Usage is implied rather than prescribed: the agent can infer this is the escape hatch for arbitrary scripting, and the description links it forward to fusion_rollback. However, it never says when to prefer this over fusion_api or fusion_ui_command, nor what prerequisites (document open, add-in state) must hold.

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

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

The annotations already establish that this is a safe, non-open-world read. The description adds useful scope by saying it checks both Fusion and the bridge add-in and reports the active document, but it does not describe failure modes or what happens when the bridge is unreachable.

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?

One compact sentence, with the core operation and diagnostic target front-loaded. Every clause contributes to the purpose.

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?

There is no output schema, so the description should carry more of the return-value burden. It says the active document is reported but does not specify how reachability results are conveyed or what a failed check looks like.

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 tool has zero parameters, so parameter semantics are not a meaningful differentiator here. Baseline 4 is appropriate because there are no arguments whose meaning the description needs to clarify.

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 states a specific verb and resource: checking reachability of Fusion and the bridge add-in, and reporting the active document. It is clear what the tool does, but it does not explicitly distinguish itself from nearby diagnostic siblings such as fusion_check or fusion_inspect.

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?

It implies a diagnostic/preflight use case but gives no explicit guidance on when to prefer this over fusion_check, fusion_inspect, or fusion_api. There are no exclusions or alternative-routing instructions.

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

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

The annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=false, so the safety profile is partly covered. The description adds meaningful behavior beyond annotations: dialog commands remain open until finished. It still does not explain what side effects a destructive command may have, whether actions can be undone, or what the caller should expect after execution.

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 two sentences with no wasted language. The primary execution behavior is front-loaded, and the second sentence adds a useful behavioral caveat.

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?

For a destructive tool that can invoke roughly 3,000 arbitrary UI commands with no output schema and zero schema descriptions, the description is quite thin. It explains the core mechanic and one dialog behavior, but omits safety context, return expectations, and details about command discovery beyond the bare mention of `search`.

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 carries the burden. It does map both parameters to their roles: `id` identifies the command to run, and `search` searches ids/names. It does not specify id format, search matching behavior, or what happens when both parameters are supplied, so it compensates only partially.

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 states a specific verb and resource: run UI commands by id, or search ids/names. The 'what a menu click does' analogy clarifies the resource. It does not explicitly differentiate this tool from close siblings such as fusion_run, fusion_api, or fusion_inspect, so it falls short of a 5.

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 two modes: execute by `id`, or use `search` when looking up command ids/names. That is useful guidance for choosing between the two parameters. However, it gives no explicit guidance on when to choose this tool over siblings like fusion_run or fusion_api, nor when not to use it.

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