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

Annotations already indicate it is not read-only and not destructive. The description adds the snapping behavior via max_search_distance and the requirement of specific fields per hole, which enriches the behavioral understanding beyond the annotations. It doesn't discuss side effects or reversibility, but that's not a major gap given the operation type.

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 with no filler. The first sentence states the purpose and required fields; the second gives usage guidance and the snapping parameter. Information is front-loaded and every phrase contributes value.

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 mutation tool without an output schema, the description covers the parameters, usage guidance, and a behavioral nuance (snapping). It doesn't mention return values or error conditions, but these are often not critical for agent invocation. The guidance to prefer auto_add_drain_holes is a strong contextual cue.

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 only 33% (only scene_id described), so the description carries the burden for explaining the drain_holes items. It details position, orientation, diameter_mm, depth_mm (with AUTO option), create_plug, and max_search_distance, effectively compensating for the schema's lack of detail. Model_id is implied by 'one model'.

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 clearly states the tool adds hand-placed drain holes to one model, specifying the resource and action. It distinguishes from the sibling auto_add_drain_holes by explicitly using 'hand-placed' and later referencing the automatic alternative.

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 explicitly says to prefer auto_add_drain_holes unless the user provides coordinates, giving a clear conditional for selecting this tool over its sibling. The context of 'hand-placed' and coordinate requirement is unambiguous.

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 description reveals the actual pipeline: it runs detect_cups, samples points under each cupped model's bounding box, lets PreForm project them at depth AUTO, and skips non-cupped models. It also explains a warning condition. This adds substantial behavior beyond the simple readOnlyHint/destructiveHint annotations, and there is no contradiction.

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 sentences, each earning its place: the core purpose, the internal algorithm, and the failure-mode alternative. Information is front-loaded and there is no redundant wording or schema repetition.

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?

The description covers the tool's workflow, skip behavior, and a warning condition, which is strong for a complex automation tool. It could additionally state what kind of result or confirmation the agent should expect after completion, but overall it is nearly complete.

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 only 50%, and the description does not explain the meaning of diameter_mm, max_holes_per_model, or scene_id. It mentions the sampling and projection approach but does not connect these concepts to the actual parameters, leaving the agent to infer how the parameters control hole placement.

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 opens with a precise verb and resource: 'Place drain holes automatically on every model that cup detection flags.' It clearly describes the automated detect-then-place workflow and distinguishes itself from the manual sibling add_drain_holes.

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 explicitly says models without cups are skipped and gives a concrete redirect: when a 'no surface found' warning appears, the cups are on a side face and the agent should offer add_drain_holes instead. This is clear when-to-use and when-not-to-use guidance.

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 indicate this is not read-only and not destructive, so the description does not need to restate that. It adds useful scope constraints but does not disclose what changes occur to the scene or models, whether the layout is persisted, or how conflicts are handled. With annotations present, this is acceptable but not richly transparent.

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 tight sentences, front-loads the core purpose, then adds scope, alternative, and special mode. Every sentence earns its place and there is 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?

The description is sufficient to decide when to call this tool and to know the SLA-only constraint. However, with 7 parameters, low schema coverage, no output schema, and no mention of the operation's effect or return value, an agent is not fully equipped to invoke it confidently beyond the selection decision.

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 only 29%, so the description needed to compensate. It enriches mode semantics ('uses the Dental Workspace layout') but leaves lock_rotation, model_spacing_mm, placement_margin_mm, and allow_overlapping_supports completely unexplained in both schema and description. This is a meaningful gap for an agent selecting parameter values.

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 clearly states the action ('Arrange models on the build platform') and the resource, and explicitly distinguishes this tool from auto_pack by printer type. This lets an agent understand what it does and how it differs from its closest sibling without opening the schema.

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 explicit guidance: SLA printers only, SLS printers should use auto_pack instead, and mode="DENTAL" changes the layout behavior. This is concrete, actionable routing that leaves little 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 declare readOnlyHint=false and destructiveHint=false, showing it is a non-readonly but non-destructive operation. The description adds useful behavior about mode selecting the Dental Workspace algorithm and tilt applying only in DENTAL mode, which is beyond the schema. However, it does not disclose side effects, error behavior, or prerequisites like scene existence.

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: the first states the core purpose, the second front-loads the parameter-specific behavior. Every word adds value; no filler or redundancy.

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 four optional parameters, no output schema, and minimal annotations, the description covers the main purpose and parameter interactions but omits return behavior, error conditions, and preconditions (e.g., models must exist, scene must be loaded). It is sufficient for basic invocation but not fully complete.

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 50% (models and scene_id have descriptions, but mode and tilt do not). The description compensates by explaining mode's algorithm selection and tilt's degree units and restriction to DENTAL mode. This adds meaning that the schema lacks for two parameters.

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: 'Rotate models to the orientation PreForm judges best for printing.' This clearly distinguishes it from sibling tools like auto_support (supports) and auto_layout (arrangement), which serve different purposes.

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?

No guidance is given on when to use auto_orient vs alternatives such as auto_layout or auto_support. The description explains what the tool does but provides no conditional context, prerequisites, or explicit exclusion of other tools.

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 state readOnlyHint=false and destructiveHint=false; the description adds meaningful behavioral context beyond annotations, such as SLS-only availability, the Fuse X1 exception, and the behavioral difference between PACK_HEIGHT and PACK_VOLUME. It does not describe what happens to existing model placements, but destructiveHint covers the broad safety profile.

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 tightly written sentences with no filler. The main action is front-loaded, followed by compatibility constraints and mode semantics. Every sentence earns its place.

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?

The description fully covers the critical compatibility and mode-selection context, which is the hardest part of this tool. However, with no output schema and low parameter schema coverage, the missing semantics for seed, model spacing, and wall distance leave the agent under-equipped for non-default configurations.

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 only 20%, so the description should compensate for undocumented parameters. It does add useful semantics for packing_mode (PACK_HEIGHT minimizes build height, PACK_VOLUME tightest packing), but it leaves seed, model_spacing_mm, and distance_from_wall_mm unexplained, creating 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?

States a specific verb and resource: 'Pack all models into the 3D build chamber.' It also distinguishes itself from the sibling auto_layout by clarifying the SLS/SLA split, so an agent can tell the tools apart.

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?

Explicitly says when to use this tool: SLS printers only, with concrete machine-type prefixes (FS or PILK). It names the alternative for SLA printers (auto_layout) and gives an explicit exclusion for Fuse X1, where PreFormServer refuses the operation.

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 indicate readOnlyHint=false and destructiveHint=false, so the tool is expected to mutate state without destroying it. The description adds little beyond 'Generate support structures' — it does not disclose whether existing supports are replaced, how the scene is affected, or whether models must be selected.

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 terse sentences with no filler. The core action is front-loaded, followed only by high-value parameter semantics that an agent needs to call the tool correctly.

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 12 parameters, no output schema, and no usage guidance, the description is not complete enough for an agent to reliably invoke the tool beyond trivial default calls. It lacks side-effect information, selection semantics, and parameter details for most fields.

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 only 17%, so the description has a responsibility to compensate. It does explain density and slope_multiplier as unitless factors around 1.0 and clarifies raft_type's allowed values, but the remaining nine parameters such as only_minima, raft_thickness_mm, and internal_supports_enabled are left to inference.

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: 'Generate support structures.' This clearly identifies the tool's function and distinguishes it from sibling tools like auto_orient, auto_layout, and auto_add_drain_holes, which target different operations.

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, nor does it mention prerequisites like needing models loaded or a scene selected. It does say to leave parameters unset for defaults, but that is operational advice, not usage context.

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 indicate readOnlyHint=false and destructiveHint=false, so the description is not expected to restate safety. It adds useful behavioral detail beyond the annotations by stating that a new scene is created and that the response includes the scene's id. This gives the agent a clear picture of the tool's observable effect and return value.

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 compact sentences with no filler. It front-loads the action and return value, then gives the input alternatives, then the source of valid codes. Every sentence earns its place.

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 create operation with no output schema, the description adequately explains the purpose, return value, valid input modes, and where to fetch allowed codes. It is slightly incomplete on how print_setting interacts with the two input modes, but the schema default and property name make this non-blocking for an agent.

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 schema covers parameter formats, but the description adds crucial relational semantics: the either/or grouping between the code-based inputs and the fps_file. It also clarifies that machine_type and material_code values must not be guessed and should come from the listed sibling tools. The optional print_setting parameter is not mentioned, but the schema provides its default, so the gap is minor.

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 action ('Create a new scene') on a clear resource ('scene for a printer and material') and names the return value. This distinguishes it from siblings like list_scenes, get_scene, update_scene, and delete_scene without requiring an agent to infer the tool's purpose.

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 explicit input-mode guidance ('EITHER machine_type + material_code + layer_thickness_mm OR the absolute path of a .fps print-settings file') and tells the agent where to obtain valid values ('Get valid codes from list_printer_types and list_materials; never guess them'). It does not explicitly compare against update_scene or explain when to prefer one input mode over the other, so it stops short of a 5.

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 mark the operation as destructive, but the description does not clarify whether the model is permanently deleted or merely removed from the scene. The phrase 'from the scene' could understate the destructive nature and does not explain side effects such as losing unsaved work or affecting dependent objects.

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 a single short sentence with no filler or redundant information. It is front-loaded with the action and target, making it easy to scan and understand.

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 operation with no output schema, the description is too sparse. It does not state whether deletion is permanent, whether the model file is also deleted, what happens to references, or how errors are surfaced. The destructive annotation covers safety, but the operational scope remains unclear.

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 schema documents scene_id but provides no description for model_id, and the tool description adds no parameter-level detail. An agent must infer that model_id identifies the model to remove, and the description does not help with format, requiredness, or relationship to scene_id.

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 a specific verb ('Remove') and a clear resource ('a model from the scene'). It is immediately distinguishable from sibling tools like delete_scene, get_model, and update_model because it names the exact object and scope.

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 no guidance about when to use this tool versus alternatives, prerequisites, or situations where it should not be used. It does not mention delete_scene or other model-related tools as alternatives, leaving the agent to infer appropriate usage from the name alone.

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 disclose destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: that deleting a scene also deletes its models, and that deleting 'default' resets it to empty rather than destroying it.

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 short sentences, front-loading the core deletion behavior and immediately providing the special-case semantics. Every word earns its place.

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 simple one-parameter tool with clear annotations, the description is mostly sufficient. The main gap is the lack of an explicit schema description for scene_id to confirm what value it takes; because schema coverage is 0%, the description should have stated that scene_id identifies an existing scene, not just handled the 'default' special case.

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 single parameter scene_id is entirely undocumented. The description partially compensates by mentioning the 'default' special value, but it does not explicitly explain that scene_id identifies an existing scene or what other values are valid.

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?

Description states 'Delete a scene and its models' with a specific verb and resource. It clearly identifies this as a deletion operation, which distinguishes it from most sibling tools, though it does not explicitly name alternatives like update_scene or list_scenes.

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 around deleting scenes and gives a special-case behavior for 'default', but it doesn't explicitly say when to use this versus alternatives or mention prerequisites like ownership or permissions. It provides some context but no explicit exclusions.

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 and non-destructive behavior. The description adds useful context that this is a count operation and that it is faster than full validation, but it does not disclose return shape, preconditions, or error behavior beyond what the annotations cover.

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 short sentences with no filler; it front-loads the core purpose and then adds a useful performance caveat. Every word earns its place.

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 simple, read-only tool with one optional parameter and no output schema, this description is largely complete: action, resource, per-model scope, and a performance hint. It lacks explicit return-type/error details, but those are not critical for such a straightforward 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?

The only parameter, scene_id, is fully documented in the schema (100% coverage), so the description does not need to add parameter detail. It adds no additional meaning beyond the schema's existing 'Scene id; omit for the default scene' 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?

Description clearly states a specific action ('count') on a specific resource ('resin cups / trapped-resin pockets per model'). It also differentiates from similar detect_* tools by focusing on trapped resin and positioning itself as faster than full validation.

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 phrase 'faster than full validation' implies a speed-oriented use case, but no explicit when-to-use/when-not-to-use guidance or named alternative tool is provided. An agent must infer when the trade-off is appropriate.

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 this as read-only and non-destructive. The description adds useful domain context by defining unsupported local minima as points that would print in mid-air, but it does not disclose additional behavioral details such as output format or error conditions.

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 focused sentence that front-loads the main action and uses the parenthetical only to clarify the key term. There is no redundant or filler wording.

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 simple read-only tool with one optional schema-documented parameter and no output schema, the description is complete: it states what is counted, defines the concept, and the annotations cover safety. Nothing essential is missing for an agent to invoke it correctly.

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 parameter scene_id is fully documented in the schema with a default value and description, so schema coverage is 100%. The tool description adds no parameter-specific meaning beyond the schema, matching the baseline.

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 action ('Count') and resource ('unsupported local minima per model'), and the parenthetical clarifies what those minima are. It is distinct enough from siblings like detect_supportedness, though it does not explicitly name an alternative.

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?

There is no guidance on when to use this tool versus alternatives such as detect_supportedness or detect_thin_walls. The parenthetical implies a print-safety use case, but no explicit context or exclusions are provided.

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 readOnlyHint=true and destructiveHint=false annotations already communicate that this is a safe read-only operation, so the description does not need to cover side effects. It adds meaningful context by indicating the output is a percentage and clarifying what 'unsupported' means via PreForm's red shading, but it does not disclose return structure, scene handling, or behavior when no models are present.

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 a single, front-loaded sentence that defines both the metric and the visual reference without wasted words. Every part earns its place: the subject, the measurement, and the clarifying 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?

For a simple read-only diagnostic with one optional parameter and no output schema, the description provides the core output semantics: a per-model percentage of unsupported surface. Minor gaps exist around the exact return container and how the optional scene_id affects the result, but these are not severe enough to undermine 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?

The schema provides 100% coverage for the only parameter, scene_id, including its default and description. The tool description adds no parameter information beyond that, so the baseline score of 3 is appropriate; the schema already carries the full semantic weight.

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 clearly identifies what the tool measures: the percentage of each model's surface that is unsupported, with PreForm's red shading as the reference. It is specific about the metric and resource, but lacks an explicit verb like 'calculates' or 'returns,' and it does not explicitly distinguish itself from sibling detect_* tools such as detect_cups or detect_minima.

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: an agent can infer this tool is for assessing unsupported surface coverage, likely during print validation. However, there is no explicit statement about when to prefer this tool over related checks like detect_cups, detect_minima, or get_print_validation, and no alternatives or exclusions are mentioned.

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 destructiveHint=false. The description adds useful behavior beyond that: it operates per model and returns volumes and bounding boxes, which are not captured in the annotations.

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 concise, front-loaded sentence with no filler. It states the action, the key parameter, the scope, and the output in a compact way.

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 read-only detection tool with three parameters and no output schema, the description covers the main input, scope, and output types. Minor gaps remain around exact return structure and behavior when no thin walls are found, but the core call is clear.

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 descriptions cover models and scene_id, but threshold_mm has no description beyond exclusiveMinimum. The description clarifies that threshold_mm is the thickness cutoff, adding meaning to the required parameter.

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 a specific verb ('Find') and resource ('wall regions thinner than threshold_mm'), plus the output type ('volumes and bounding boxes'). This clearly distinguishes it from sibling detection tools like detect_cups or detect_minima.

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 purpose: use this when you need to detect thin walls in models. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives, so the agent must infer selection from the name and description.

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 destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that passing ip_address probes a single host rather than scanning the whole network, which is useful. It does not disclose timeout behavior, output format, or failure modes, but the annotations lower the burden.

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 with no filler. The main action is front-loaded, and the optional parameter behavior is stated in the second sentence. Every word earns its place.

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 read-only network scan tool with no output schema, the description covers the core purpose and the optional single-host probe. However, it omits what the scan returns, how timeout_seconds affects behavior, and any network/prerequisite context. Given the tool's simplicity and annotation coverage, this is adequate but not complete.

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 ip_address ('probe one host') but says nothing about timeout_seconds, which is a parameter with a default and wide range. The description adds some meaning for one parameter but leaves the other undocumented.

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 ('Scan') and resource ('local network for Formlabs printers'), and distinguishes the single-host probe behavior from the general scan. It is clear enough to differentiate from sibling tools like list_devices and get_device, though it doesn't explicitly name those 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?

The description implies when to use the tool: scanning the local network, or probing one host with ip_address. It does not explicitly state when not to use it or name alternatives like list_devices/get_device, so the guidance is present but not fully explicit.

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 indicate this is a mutating operation (readOnlyHint: false) but not destructive (destructiveHint: false). The description adds useful context by stating the tool returns the scene and that layout should be run afterward. However, it does not disclose whether the original model is preserved or whether a new model ID is created, leaving some behavioral ambiguity.

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 short sentences provide the essential behavior, return value, and required follow-up action with no wasted words. The structure front-loads the core purpose before the operational tip.

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 simple three-parameter tool with no output schema, the description is largely complete: it states what action to take, what is returned, and what should happen next. The only minor gap is not explicitly stating that `model_id` must reference an existing model, but this is reasonably inferred from the tool name and sibling context.

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 only 33%, with model_id lacking a description. The description adds some meaning by explicitly tying `count` to the duplication behavior, but model_id semantics are not addressed. scene_id is already covered in the schema, so the description only partially compensates for the low coverage.

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 a specific verb ('Make') and resource ('copies of a model'), exactly matching the tool name while adding the count behavior and return value. It is clearly distinguished from mutation siblings like update_model, replace_model, and delete_model.

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 explicit follow-up guidance: 'Run auto_layout or auto_pack afterwards.' This tells the agent when and how to proceed after duplication. It does not name alternative duplication tools, but no direct sibling alternative exists, so the guidance is sufficient.

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 destructiveHint=false. The description adds useful context that the estimate depends on material usage read from get_scene and reports seconds, but it does not disclose edge cases, failure behavior, or required scene state beyond the schema.

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 short, front-loaded sentences. The first states the operation and output unit; the second gives a useful dependency pointer. 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 one optional parameter, read-only annotations, and no output schema, the description is nearly complete: it states units, the scene scope, and the dependency on get_scene. It could more explicitly state prerequisites or error conditions, but nothing essential is missing for a simple estimation 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 100%: the only parameter, scene_id, is already fully described in the input schema. The description adds no new parameter detail beyond referring to 'the scene,' which matches the schema baseline.

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?

Clearly states a specific action ('Estimate print time') on a specific resource ('the scene') with explicit output units ('in seconds'). This distinguishes it from sibling tools like detect_cups or print_to_printer.

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?

Implies a dependency on get_scene by saying 'Read material usage from get_scene,' which suggests using get_scene first. However, it does not explicitly state when to use this tool versus alternatives or 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.

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

Annotations already indicate a non-read-only, non-destructive operation, so the description does not need to re-establish basic mutation safety. It adds useful behavior: duplication until full, packing, return of new model IDs, and partial-fill support. However, it leaves ambiguity about whether existing models in the scene are also packed or moved, and does not state that original models remain untouched.

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 with no filler: the core action is front-loaded, the return value is stated, and the optional behavior is given in a conditional clause. Every sentence earns its place.

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?

The description covers the main purpose, return value, and a key optional parameter, which is helpful given no output schema. However, with five parameters and no output schema, it leaves important context unstated: how 'full' is determined, whether existing scene models are considered, and the roles of spacing/wall distance parameters. It is adequate but not complete.

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 only 40%, so the description is expected to compensate. It adds meaning to `fill_to_height_mm` but does not explain `model_spacing_mm` or `distance_from_wall_mm`, which remain undocumented in both the schema and the description. The names are somewhat self-explanatory, but the description only partially fills the 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 a specific verb ('Duplicate') and resource ('given models'), states the goal ('until the SLS build chamber is full and pack them'), and gives the return value (`new_model_ids`). It also distinguishes itself with 'SLS only', which separates it from sibling tools like fill_build_platform.

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 explicitly limits the tool to SLS builds, which tells an agent when not to use it. It also explains that `fill_to_height_mm` is for partial fills. It does not name specific sibling alternatives, but the SLS-only constraint provides clear usage context.

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 only indicate non-read-only and non-destructive. The description adds meaningful behavioral context: it duplicates models, creates copies, returns new_model_ids, and applies only to SLA. It does not explain all side effects on the existing scene, but duplication plus new IDs strongly implies originals are preserved.

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 words. It front-loads the primary action, then adds scope, return value, and the sibling alternative, all in an efficient structure.

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 mutating tool with four optional parameters and no output schema, it covers the core action, SLA constraint, return value, and SLS alternative. The main gap is the lack of detail on spacing and margin parameters, plus limited clarity on what happens to existing models in the scene.

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 only 50%. The two undocumented parameters, model_spacing_mm and placement_margin_mm, are not explained in the description, including their units, defaults, or how they affect the layout. The description only implies they influence fitting. The documented parameters, models and scene_id, are already covered by the schema.

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 clearly states the action ('Duplicate the given models as many times as fit and lay the copies out'), the resource, the SLA-only scope, and the output ('returns new_model_ids'). It also names the sibling tool it is not, making it easy to distinguish from fill_build_chamber.

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 explicitly restricts usage to SLA printers ('SLA only') and gives a direct alternative for SLS printers ('For SLS printers use fill_build_chamber.'). This is clear when-to-use and when-not-to-use guidance.

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 destructiveHint=false, matching the non-mutating status read. The description adds the status dimensions but does not disclose response shape, error behavior, or edge cases. No contradiction with annotations.

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 states the object, scope, and the three status categories without filler. Every word carries 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?

For a one-parameter, read-only status call with annotations covering safety, the description is largely complete: it gives the resource, the status dimensions, and the required device_id is inferable from context. The main gap is no explicit return structure, but there is no output schema to elaborate.

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 description does not explicitly define device_id or its format. However, 'status of one printer' implies that the required device_id identifies the printer, providing minimal connective meaning beyond the bare schema.

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 resource (one printer) and enumerates the exact status categories returned (connection, tank/cartridge material, time remaining). The singular scope distinguishes it from collection-oriented siblings like list_devices and discover_devices.

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?

There is no explicit guidance on when to call this tool versus list_devices/discover_devices, nor any mention of how to obtain a valid device_id. The intended usage is only implied by the word 'one printer'.

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 destructiveHint=false, so the safety profile is covered. The description adds the specific criterion (overlap or proximity threshold) but does not disclose additional behavior such as scene scoping, return format details, or whether all models are considered. It does not contradict annotations.

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 a single, efficient sentence that front-loads the core action and condition. There is zero waste; every word contributes to understanding the tool's function.

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 clarify return format. It mentions 'pairs of model ids', which is helpful, but it does not specify the scope (e.g., whether it considers only models in the given scene, or all loaded models) or edge cases (empty scene, missing collision_offset_mm). The description is adequate for a simple read-only tool but leaves some ambiguity.

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 50%: scene_id is fully described in the schema, while collision_offset_mm has no schema description. The description compensates by explaining that this parameter defines the proximity threshold, giving it semantic meaning beyond its name. This adds value for the undocumented parameter.

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 ('List') and resource ('pairs of model ids') with a precise condition (overlap or closer than collision_offset_mm). It clearly differentiates from sibling tools like detect_thin_walls or detect_cups, which focus on feature detection rather than interference listing.

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 for interference checking but provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions. The context of listing overlapping/proximal model pairs is implicit but not framed against sibling detection tools.

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 destructiveHint=false, so the safety profile is covered. The description adds value by specifying the exact returned property set, which is useful behavioral/return information. It does not cover missing-model error behavior, but that is minor for a simple read operation.

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 sentence that front-loads the verb and resource, then lists the exact properties. There is no filler or redundant 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?

For a simple read-only tool with two parameters and safety annotations, the description covers the return contents and the schema covers parameter definitions. A note about scene_id's role or missing-model behavior would improve completeness, but nothing critical is absent.

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?

Only scene_id has a schema description; model_id is undocumented. The tool description does not clarify model_id's format, source, or relationship to scene_id, so it fails to compensate for the 50% schema description coverage 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?

Description uses a specific verb ('Get') and resource ('one model's properties') and enumerates the exact properties returned: transform, bounding box, supports, lock state. This clearly distinguishes it from sibling tools like get_scene, get_user, or get_device.

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 intended use is implied by the resource name and the explicit 'one model' phrasing, but the description gives no when-to-use guidance or exclusions versus siblings. It does not mention alternatives such as get_scene or list_scenes, leaving the agent to infer context.

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 destructiveHint=false, covering the safety profile. The description adds useful context by listing the fields returned, but it does not disclose behavior around missing scenes, multiple models, error cases, or output structure.

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 concise sentence with no filler. The core purpose is front-loaded and the field list is compact and informative.

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 read-only tool with one optional parameter and no output schema, the field list plus annotations make it mostly complete. The main gap is the lack of detail on how per-model results are returned and how the scene_id parameter selects models.

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 schema describes scene_id with 100% coverage, so the baseline is 3. The description does not add any parameter-level meaning beyond the schema and does not clarify how 'per model' relates to scene_id.

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 ('get') and resource ('print validation'), and identifies it as a 'full printability check per model' listing four concrete result fields. This distinguishes it from the individual detect_* sibling tools, which each target a single check.

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?

There is no explicit guidance about when to use this tool versus the detect_cups, detect_minima, detect_supportedness, or other sibling tools. The word 'full' implies aggregation, but no clear when-to-use or when-not-to-use context is provided.

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 destructiveHint=false, and the description adds the actual return scope, which is especially valuable since there is no output schema. It communicates that the operation is a safe read that summarizes a scene's contents, going beyond the annotations.

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 that states the action and enumerates the key returned data without fluff. Every phrase adds information an agent needs to understand the tool's scope.

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?

The tool is simple (one optional parameter, no output schema), and the description covers the main return categories. It is complete enough for an agent to call correctly, though it could mention default-scene behavior or error cases, but those are largely covered by the parameter schema and annotations.

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%: scene_id has a clear description and default. The tool description does not add parameter-level detail, but with full schema coverage the baseline of 3 is appropriate.

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 ('Get') and resource ('a scene'), then enumerates the returned content: models, bounding boxes, supports, print settings, material usage, and build volume. This distinguishes it from siblings like get_model, list_scenes, and update_scene without needing to open schemas.

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 is clearly a read-only retrieval tool for a single scene, so when to use it is implied. However, there is no explicit guidance about when to prefer get_scene over list_scenes or get_model, nor any exclusions or prerequisites.

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 mark the tool as read-only and non-destructive. The description adds the stateful context that it returns the currently logged-in account and depends on a prior `login`, which is useful behavioral information beyond the annotations. It does not describe the not-logged-in failure mode, but this is a minor gap.

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 that conveys the purpose and the prerequisite without any filler. Every word earns its place.

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 zero-parameter, read-only state query with no output schema, the description is complete: it identifies what is returned and when to call it. The agent has enough information to select and invoke the tool correctly.

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 the baseline is 4. The description does not need to explain parameters because there are none, and the schema confirms this with 100% coverage.

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 a specific verb ('Return') and a specific resource ('the Formlabs account currently logged in'), which clearly distinguishes it from sibling tools like login, logout, and list_devices. The parenthetical '(after `login`)' reinforces its role as a state query rather than an action.

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 explicitly notes that this should be used after `login`, giving the agent a clear precondition. It does not name alternatives or exclusions, but for a simple getter with zero parameters, the usage context is clear enough.

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=true and destructiveHint=false, and the description adds value beyond that by disclosing the side-effect that 'it starts PreFormServer if needed.' This is genuinely useful behavioral context (potential startup cost/latency, process launch) not captured by the annotations, and it does not contradict them.

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 with zero filler. The primary purpose is front-loaded, and the supplementary behavioral note about starting the server earns its place. Nothing extraneous.

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 zero-parameter tool whose annotations already cover the safety profile, the description is nearly complete: it states the return value (version) and the reachability check. It lacks an explicit return format and does not address the overlapping preform_status sibling, which keeps it from a 5.

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 and schema coverage is 100%, so there is nothing for the description to add. Per the baseline for parameter-free tools, a 4 is appropriate.

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: 'Return the PreFormServer version' and 'confirm the server is reachable.' The purpose is unambiguous and actionable. However, it does not distinguish itself from the sibling 'preform_status,' which appears to overlap in purpose, so differentiation is left to the agent.

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 gives explicit temporal guidance — 'Call this first to confirm the server is reachable' — which tells the agent when to invoke it. But it never names alternatives like preform_status or states when NOT to use this tool, leaving the sibling distinction unresolved.

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 are both false, so the description carries the burden of disclosing behavioral traits. It reveals that hollowing creates internal cavities that trap resin, requiring drain holes – a behavior not stated in any structured fields. However, it doesn't mention reversibility, permissions, or side effects on existing models, so it's not 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?

The description is two short sentences with no wasted words. The action and purpose are front-loaded, and the follow-up instruction is a necessary addition without extra verbosity.

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 mutation tool with 4 parameters and no output schema, the description leaves critical gaps. The meaning of feature_size_mm and wall_thickness_mm is absent, there are no prerequisites or side-effect warnings, and the return value is not addressed. The follow-up hint is helpful but insufficient for an agent to call the tool confidently.

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 description adds no information about the parameters. With schema coverage at 50%, feature_size_mm and wall_thickness_mm are undocumented, and the description fails to compensate by explaining what these parameters control. It also doesn't reinforce the meaning of models or scene_id beyond their schema descriptions.

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 ('hollow') and resource ('models') with the explicit purpose 'to save resin'. It also indicates a distinct step from siblings by referencing auto_add_drain_holes as a follow-up, which differentiates its role in the workflow.

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 clear context for when to use the tool ('to save resin') and gives an explicit follow-up instruction ('Follow up with auto_add_drain_holes'), implying sequencing without alternatives or exclusions. This is more than an implied usage, but it doesn't mention when not to use it or compare with other tools.

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?

Discloses defaults that differ from the raw API, the post-import scene re-read, and the exact failure mode IMPORT_PRODUCED_EMPTY_SCENE with a 'do not retry' instruction. This is substantial behavioral context beyond the basic readOnly/destructive annotations.

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?

Four sentences, each adding essential information: purpose, path requirement, default/unit guidance, and failure behavior. No filler, and the most important constraints are front-loaded.

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 9-parameter tool with no output schema, the description covers the core workflow, output shape, and a critical failure mode. It is not fully complete because some parameter semantics are absent, but combined with the schema it gives an agent enough to call the tool successfully.

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 only 22%, and the description compensates for file, units, and repair_behavior with meaningful guidance. However, it leaves several parameters (name, scale, position, split_multi_model_file) unexplained, so it only partially bridges the coverage 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 first sentence names the action (import), the resource (model file), supported formats (STL, OBJ, 3MF, STEP), and target (scene), and the return value (model with id). This makes it easy to distinguish from sibling model operations even without naming them.

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 concrete usage constraints: file must be absolute, units should be INCHES for inch files or DETECTED to let PreForm guess, and malformed files should not be retried. It does not explicitly name alternative tools, so it falls short of a 5, but the context is clear.

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 mark this as destructive, but the description goes well beyond that by disclosing download size, signature verification, user-owned installation location, the requirement to ask the user, and idempotent no-op behavior. This gives the agent a realistic picture of side effects and safety.

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 short sentences, each carrying distinct information: what the tool does, when to use it, and that it is idempotent. No filler or repetition of schema 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?

For a single-parameter installation tool with no output schema, the description covers the essential context: what is being installed, where, why it is safe to repeat, and the user-consent requirement. Nothing critical is missing for an agent to decide whether and how to call it.

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% for the only parameter, force, so the schema fully documents parameter meaning. The description does not need to add more, and adding none is acceptable given the baseline of 3.

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 clear chain of actions (download, verify signature, install) on a specific resource (PreFormServer from Formlabs) and adds a distinctive detail (user-owned folder). It is easy to distinguish from siblings like preform_status or health_check because the verb and resource are explicit.

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 usage context: ask the user first and call safely again because it no-ops when already latest. It does not explicitly name a sibling tool as an alternative, so it stops short of a perfect 5, but the conditions for calling are clear.

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?

Beyond the readOnlyHint=false and destructiveHint=false annotations, the description adds meaningful behavioral detail: position is a label centre in scene mm, and orientation uses Euler degrees with explicit text direction and surface-normal conventions. It does not mention permanence or failure conditions, but the coordinate and orientation semantics are valuable.

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 filler. The core action is front-loaded, and the coordinate/orientation details are packed into a single follow-up sentence that directly supports correct invocation.

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 tool with 8 parameters, nested objects, no output schema, and mutation annotations, the description gives a solid start but leaves gaps: it does not state the return value, the effect of depth_mm sign, or whether the operation modifies the model in place. It is sufficient for a first attempt but not fully complete.

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 only 25%, so the description needs to compensate. It does clarify position and orientation semantics, which are the two most ambiguous parameters, but it does not explain depth_mm, font_size_mm, label, model_id, or application_mode beyond their names/enum. This is partial compensation, not 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?

The description opens with a specific verb and resource: 'Emboss or engrave text onto a model's surface.' This clearly distinguishes label_model from model-level operations like update_model, hollow_model, or auto_orient, and the two operation modes (EMBOSS/ENGRAVE) map directly to the application_mode enum.

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 makes the intended use obvious: adding text labels to a model. It does not explicitly name alternatives or exclusions, but no sibling tool appears to provide labeling behavior, so the context is clear enough for an agent to select this tool when text needs to be applied.

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 destructiveHint=false. The description adds behavioral context beyond that: LAN discovery is cached until discover_devices is run, Fleet/Dashboard printers require login, and virtual printers accept print_to_printer as a hardware-free dry run. No contradiction with the annotations exists.

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 a single long but information-dense sentence that front-loads the core purpose before enumerating categories. Every clause adds useful context, though the dry-run clause is somewhat elaborate and makes the sentence heavier than necessary.

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 read-only list tool with one optional parameter and no output schema, the description covers device categories, refresh behavior, login dependency, and virtual-printer use cases well. The main missing piece is the meaning of can_print, which would make the definition fully complete.

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 input schema has one optional boolean parameter, can_print, with 0% description coverage, and the description never mentions it. An agent must infer the intended filtering behavior from the parameter name alone, so the description fails to compensate for the schema 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 opens with a specific verb and resource: 'List printers PreFormServer knows', then enumerates the exact printer categories: discovered LAN printers, Fleet Control queues, Dashboard printers, and virtual printers. It also implicitly differentiates itself from discover_devices by pointing out that discovery must be refreshed separately, and from physical printing by describing virtual printers as a hardware-free dry run.

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 gives clear context for when to use the tool: after running discover_devices for LAN printers and after login for Fleet Control/Dashboard printers. It explicitly names discover_devices as the refresh alternative, but it does not state exclusions such as when to use get_device or list_printer_types.

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 destructiveHint=false, so the safety profile is known. The description adds the behavioral fact that the full list is large (affecting response size/performance) and explains that scene_settings contains exact values needed for create_scene, which is valuable context beyond the annotations.

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 filler. The primary purpose and the key relationship to create_scene are front-loaded, followed by a single actionable usage note. Every clause earns its place.

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 simple read-only list tool with one optional parameter and no output schema, the description covers purpose, parameter usage, and hints at the response structure (scene_settings fields). Nothing an agent needs to call it correctly is missing.

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?

With 0% schema description coverage, the description fully compensates by explaining that machine_type filters to one printer family and that the list is large without it. This gives the parameter clear semantic meaning that the schema alone (a bare string) lacks.

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 clear verb ('List') and resource ('printers with their materials and print settings'), and distinguishes itself from siblings like list_printer_types by focusing on materials and settings. It also ties the output to create_scene, making its unique purpose explicit.

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 explicitly advises passing machine_type to filter to one printer family because the full list is large, which is a clear usage condition. It doesn't name alternatives, but the link to create_scene implies when this tool is needed, and the filter guidance is actionable.

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 destructiveHint=false. The description adds useful behavioral detail beyond that: it is a 'short list', it does not yet include every accepted family, and unlisted families carry an `unlisted` note. This helps set expectations about coverage.

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 compact and front-loaded, stating the core purpose first, then the mapping use case, then the code-family semantics, and finally the coverage caveat. Every sentence adds meaningful guidance; no filler or repetition.

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 zero-parameter read-only list tool with no output schema, the description is complete: it explains what the output contains (families, machine_type codes, build volumes), how to use it, and a caveat about accepted-but-unlisted families. Nothing essential is missing for the agent to invoke or interpret the tool correctly.

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?

With zero parameters and 100% schema coverage, there is nothing for the description to clarify about parameters. The baseline of 4 is appropriate, and the description does not introduce any parameter confusion.

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 ('list'), a clear resource ('printer families'), and the key contents ('machine_type codes and build volumes'). It also names the exact use case: mapping printer names to machine_type before create_scene, which distinguishes it from sibling tools like list_devices or list_materials.

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 explicitly says when to use it ('before create_scene') and explains how to interpret the results for different workflows ('SLA (auto_layout)' vs 'SLS (auto_pack)'). It does not explicitly name alternatives or give when-not-to-use conditions, but the context is clear enough.

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 destructiveHint=false, covering safety. The description adds the meaningful context that scenes are held in memory, implying a non-persistent snapshot, but provides little beyond that. No contradiction with annotations.

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 says exactly what the tool does and adds the important in-memory scope. There is no filler or redundant restating of the tool name.

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 zero-parameter, read-only list operation, the description is complete. Annotations cover safety, and the scope is stated clearly. No return-format or pagination expectations are necessary for such a simple 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?

The tool has zero parameters and schema coverage is 100%, so the description has no parameter meanings to add. Per the baseline for zero-parameter tools, this is appropriately handled.

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 a specific verb ('List'), names the exact resource ('every scene'), and adds the scoping detail 'currently holds in memory.' This clearly distinguishes it from get_scene, which presumably retrieves a single scene, and from create/update/delete operations.

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 the tool is for full enumeration of in-memory scenes, but it does not explicitly state when to choose this over get_scene or mention any exclusions. The 'every scene' phrasing gives context, but guidance is implied rather than stated.

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 indicate readOnlyHint=false and destructiveHint=false, so the description is not contradicting them. The description adds the constraint that 'file' must be an absolute path, which is useful behavioral context. However, it does not disclose what happens if the file does not exist, whether the current scene is replaced, or any side effects on the scene state.

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 words. The key action and the critical parameter constraint are front-loaded, making it easy for an agent to parse quickly.

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 has only one parameter and no output schema, the description covers the essential action and the key parameter constraint. However, it lacks context about error conditions, side effects on the current scene, and whether this is a server-side file operation. For a tool that loads a file into a scene, an agent might need to know if the scene is replaced or if a new scene is created.

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 does add meaning by specifying that 'file' must be an absolute path and that it refers to a .form file. However, it does not explain the expected file format details, whether the path should be a local filesystem path or a server-side path, or any constraints on the file content.

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 ('Open') and resource ('.form file as a new scene'), which clearly distinguishes it from sibling tools like save_form or create_scene. It could be slightly more explicit about the relationship to create_scene, but the core purpose is unambiguous.

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 context: it is for opening an existing .form file, as opposed to creating a new scene or saving a form. However, it does not explicitly state when to use this tool versus alternatives like create_scene or import_model, nor does it mention any prerequisites (e.g., file must exist, server must be running).

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 are minimal (readOnlyHint=false, destructiveHint=false), so the description carries most of the burden. It clearly states that credentials never pass through the conversation, which is a key behavioral detail about authentication and how credentials are handled. This disclosure is valuable and goes beyond the schema. However, it doesn't describe what happens on success or failure (e.g., session token behavior), but given that the tool is a login, the provided info is sufficient.

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 concise, two sentences with no fluff. It front-loads the purpose, then immediately provides the critical usage instructions. Every word is necessary; no redundant 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?

For a zero-parameter tool, the description covers everything an agent needs: what the tool does, how to configure credentials, and how to call it. Since there is no output schema, the description doesn't need to explain return values, but it's clear enough for an agent to use effectively. The siblings (logout) provide contrast, and the lack of parameters makes this complete.

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, and the schema description coverage is 100% (effectively covering nothing). The description adds no parameters but explains the configuration mechanism (environment variables) and why no arguments are needed. This is essential context that the schema cannot convey, so the description provides significant value beyond the schema.

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 clearly states the tool's purpose: to log in to Formlabs Web Services for remote printing and Fleet Control/Dashboard printers. It uses a specific verb ('Log in') and resource, distinguishing it from siblings like logout and health_check. The context of remote printing and management is clearly conveyed.

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 explicitly instructs that credentials must be set in environment variables (FORMLABS_USERNAME, FORMLABS_PASSWORD, or FORMLABS_ACCESS_TOKEN) and that the tool should be called with no arguments. This is critical because the schema has zero parameters, so the description provides the only usage guidance. It also implies that login is a prerequisite for other operations, though it doesn't explicitly say 'use this before other tools'.

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 are minimal (readOnlyHint: false, destructiveHint: false) and the description adds no behavioral context beyond the action name itself. It does not disclose side effects like invalidating tokens, clearing session state, or making subsequent authenticated calls fail. With no additional transparency, this is a significant gap for a state-changing operation.

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 a single, sharp sentence that states the action and target with no filler. Every word earns its place, and the purpose is front-loaded.

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 simple, parameterless logout operation with no output schema, the description is mostly complete. It could have mentioned the effect on authentication state or the need to re-login afterward, but the core action is clearly conveyed and nothing essential for calling the tool is missing.

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 and the schema is empty, so there is no parameter information missing. The description correctly implies that no arguments are needed, which is sufficient for a parameterless tool. Baseline 4 applies here.

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 ('Log out') and a clear resource ('Formlabs Web Services'), making the action unmistakable. It also differentiates itself from the sibling 'login' tool and other tools by naming exactly what it terminates.

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?

No guidance is given about when to use this tool versus alternatives, such as pairing it with 'login' or what to do if already logged out. The description only states what it does, leaving usage context entirely to the agent's 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?

The annotations already indicate a non-read-only operation, and the description adds useful behavior: it builds a cage, packs models, acts on the most recent scene, and returns that scene. It does not contradict the annotations, though it leaves open whether prior cages are replaced.

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 compact and front-loaded with the action, then adds constraints, parameter detail, and return value in a few tight clauses. Every sentence 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?

It states the return value and key constraints, which is good with no output schema. However, it omits prerequisites such as requiring an existing most-recent scene and loaded models, and it leaves cage_label and model_spacing_mm semantics under-defined.

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?

Only one of four parameters has a schema description, and the description only adds meaning for packing_type by listing its enum values and default. cage_label and model_spacing_mm remain unexplained, including missing units for the spacing value. Low schema coverage means the description needed to compensate more than it does.

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 and resource ('Pack models and build a printed cage') and scopes the operation to SLS printing and the most recently created scene. This clearly differentiates it from generic packing/layout siblings like auto_pack.

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 explicit context for when the tool applies: SLS only, and it acts on the most recently created scene. It does not name alternatives for other cases, but the constraints are clear enough for an agent to select it appropriately.

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 destructiveHint=false, so the description does not need to restate the safety profile. It adds valuable context beyond the annotations by specifying 'without touching PreFormServer'—a stronger guarantee than generic read-only—and by disclosing the specific items it reports, including the Wine-specific path rewriting behavior. This helps the agent understand exactly what information it will get without side effects.

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 a single, information-dense sentence that front-loads the main action ('Report how this MCP server is set up without touching PreFormServer') and then lists the specific data points it covers. Every word earns its place, with no filler or repetition of the tool name, making it appropriately sized and efficient.

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 read-only status tool with no parameters and no output schema, the description fully covers what an agent needs to know: what the tool does, what it reports, and when to use it relative to health_check. It even addresses the failure case ('whether PreFormServer is installed') and the Wine-specific path mapping, leaving no critical gap 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?

The tool has zero parameters and schema coverage is 100%, so there are no parameters for the description to explain. Per the rubric, a zero-parameter tool gets a baseline of 4, and the description adds no irrelevant parameter details. It correctly focuses on the tool's behavior rather than on parameters that do not exist.

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 clearly states a specific action ('Report how this MCP server is set up') and enumerates the exact resources and aspects it covers: installation location, version, mode, allowed directories, and path rewriting. It also distinguishes itself from the sibling health_check by positioning this as a pre-check that does not touch PreFormServer, so an agent can differentiate it without opening schemas.

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 explicitly says 'Use it to diagnose setup problems before health_check', providing a concrete when-to-use directive and naming the related sibling health_check. It also implies a non-use case with 'without touching PreFormServer', but it does not explicitly state when not to use it or list alternative diagnostic tools beyond health_check, so it is clear but not exhaustive.

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 mark this as destructive and non-read-only. The description adds useful behavioral context: jobs can be queued or started immediately, Fleet Control queue ids require login, and virtual printers enable dry runs without hardware. This goes beyond the annotations without contradicting them.

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 compact and front-loaded with the action, followed by user-confirmation guidance and parameter-specific details. Every clause carries necessary information; there is no redundancy or 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 destructive print tool with no output schema, the description covers the essential return value (job_id), queue behavior, printer identifier variants, and the need for user confirmation. Minor gaps remain around error behavior and the timeout parameter, but the description is complete enough for typical usage.

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 only 20%, so the description must compensate. It thoroughly explains printer and print_now, but does not describe job_name or find_printer_timeout_seconds. The latter is only somewhat inferable from its name, and the description does not clarify its purpose or effect.

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: 'Upload the scene to a printer and queue it, or start it.' This clearly distinguishes the tool from siblings like list_devices, estimate_print_time, and preform_status, and explains the core action without ambiguity.

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 explicit operational guidance: confirm with the user first, then explains printer identifier formats and the behavior of print_now. It does not name alternatives or exclusion cases, but no direct sibling does the same job, so the context is largely sufficient.

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 and destructiveHint=false, so the description doesn't need to restate that. The description adds valuable behavioral context: the operation preserves placement and supports, and it requires an absolute path. It doesn't disclose whether the old mesh is destroyed or whether the operation is reversible, but the annotations already signal non-destructive intent. This is a reasonable level of transparency beyond the annotations.

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 sentences, each earning its place: the action, the use case, and the critical file-path constraint. No filler, no repetition of schema details. The most important operational detail (absolute path) is front-loaded at the end of the description.

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 mutation tool with no output schema and only 25% schema description coverage, the description covers the core purpose and the key file constraint, but it leaves `repair_behavior` unexplained and doesn't mention what happens to the old mesh or whether the operation is reversible. An agent could call it correctly for the common case, but edge cases around repair behavior are under-specified.

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 only 25%, so the description must compensate. It does explain the critical `file` parameter ('must be an absolute path') and implies `model_id` is the target. However, it does not explain `repair_behavior` (REPAIR/ERROR/IGNORE) or `scene_id` beyond what the schema already says. The description adds some value but leaves the enum parameter's semantics to the schema, which only lists the enum without explaining what each value does.

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 ('Swap'), a specific resource ('a model's mesh'), and the key behavioral constraint ('while keeping its placement and supports'). It also names the use case ('when the user re-exports a revised part'), which distinguishes it from generic update_model and import_model siblings. This is a clear, specific purpose statement.

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 a clear context for use ('when the user re-exports a revised part') and a critical prerequisite ('file must be an absolute path'). It does not explicitly name alternatives or say when not to use it, but the context is strong enough that an agent can infer when to select it over siblings like update_model or import_model.

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 mark the tool as destructive, but the description adds crucial specificity: it overwrites silently and the agent should confirm with the user first if the file exists. This clearly discloses what gets destroyed without contradicting annotations.

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 short sentences with no wasted words. The core action is front-loaded and the safety caveat follows naturally.

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 simple two-parameter tool with one required parameter and no output schema, this description covers the action, target format, path requirement, and destructive overwrite behavior. No critical operational fact is missing.

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 schema documents scene_id but leaves 'file' as a bare string. The description compensates by clarifying that the file parameter expects an absolute path to a .form file, adding meaning beyond the schema.

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 action ('Save the scene'), target format ('.form'), and path constraint ('absolute path'). This makes it easy to distinguish from load_form and the other scene-management tools without opening the schema.

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 intended use is implied: this is the tool for saving a scene to a .form file. However, it does not explicitly name alternatives or state when not to use it, such as when loading a .form file instead.

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 disclose that this is a write operation (readOnlyHint=false) and potentially destructive (destructiveHint=true). The description adds the useful context that it export settings for reuse with create_scene, but it does not disclose details such as whether an existing .fps file will be overwritten or how file paths are resolved. Given annotation coverage, a 3 is appropriate.

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 sentence that packs the action, target, format, and downstream purpose with no filler. It is front-loaded with the verb and resource and earns every word.

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 tool with no output schema, the description is mostly sufficient, but it leaves gaps: it does not clarify file path semantics, overwrite behavior, or what the tool returns on success/failure. The destructive annotation partially covers the risk profile, but the missing file semantics prevent a higher score.

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 only 50% because the required 'file' parameter has no description. The description does not compensate by explaining the 'file' parameter's meaning beyond the implicit '.fps file' target, nor does it add detail about path requirements or extension handling. The optional 'scene_id' is already documented in the schema.

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 a specific verb ('Export') and names the exact resource ('scene's print settings') and output format ('.fps file'). It also states the intended purpose ('for reuse with create_scene'), which clearly differentiates it from sibling export tools like save_form and save_screenshot.

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 clear context for when to use the tool: before or in preparation for create_scene. It does not explicitly list alternatives or exclusions, but the stated purpose is enough for an agent to select it correctly in most workflows.

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 write nature is known. However, the description adds no additional behavioral context, such as whether an existing file is overwritten, whether the file must be .png or .webp specifically, or if any permissions are needed. It simply restates the action without enriching the annotation-provided safety profile.

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 fluff. It front-loads the core action and then provides the enum values for view_type. Every sentence earns its place and there is no redundancy.

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 tool with 6 parameters, 1 required, no output schema, and sparse annotations, the description is far too thin. It does not explain yaw, pitch, image_size_px, or the file path semantics, nor does it mention defaults or how the scene_id default works. An agent would struggle to construct a correct call without additional schema or tooling hints.

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 only 17% (only scene_id has a description). The description does explain view_type and its enum values, which is helpful, but it does not clarify the meaning or format of yaw, pitch, image_size_px, or the required file parameter. With low coverage, the description should compensate for all undocumented parameters, but it only addresses one.

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 (Render), a resource (the scene), and the output format (.png or .webp) at an absolute path. It also names the view_type enum values, which clearly distinguishes this tool from all siblings, none of which perform screenshot rendering.

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?

No guidance is given on when to use this tool versus alternatives. There are no similar sibling tools, but the description does not mention any context like 'use this to capture an image for documentation' or any prerequisites. The agent must infer usage solely from the name and purpose.

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 say the tool is not read-only and not destructive. The description adds behavioral context beyond those flags: position units in millimeters, orientation in Euler degrees, and the precise meaning of the lock enum for auto_layout / auto_pack behavior. It does not contradict the annotations and provides meaningful detail for a mutating operation.

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 sentences with no filler. The first sentence is a compact verb list that immediately conveys purpose, while the remaining sentences pack unit and enum semantics into clear, separable clauses. Everything included earns its place.

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 7-parameter mutation with no output schema, the description is helpful but not fully complete. It documents position/orientation formats and lock semantics, but scale behavior is ambiguous, no return/response behavior is described, and scene_id is only covered in the schema. An agent could call correctly for transform and lock operations but may mis-specify scale or misunderstand what the call returns.

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 only 29%, so the description carries the burden for parameter meaning. It adds units to position, clarifies orientation format, and enumerates the lock values that the schema omits. However, scale is left undefined (is it a factor? relative to what origin?) and scene_id/name semantics are only implied, so the compensation is incomplete.

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 resource 'model' and a precise verb list: 'Move, rotate, rescale, rename or lock a model.' This is far more specific than the generic title 'update_model' and distinguishes it from sibling mutation tools like delete_model, duplicate_model, or replace_model.

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 useful context by explaining how `lock` interacts with auto_layout / auto_pack, which implies when changing the lock state matters. However, it never explicitly states when to use this tool versus alternatives like replace_model or duplicate_model, nor does it mention prerequisites or ordering.

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 and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds the key behavioral guarantee that models are kept, which is valuable context beyond the annotations. However, it does not disclose other behavioral traits such as whether changes are validated, whether partial updates are allowed, or what happens if an invalid material/printer combination is provided. With annotations covering the safety profile, a 3 is appropriate.

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 sentence that is front-loaded with the action and resource, lists the modifiable attributes, and includes the key non-destructive guarantee. Every word earns its place; no filler or redundancy.

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 mutation tool with no output schema and low parameter documentation, the description is somewhat thin. It covers the core purpose and the non-destructive aspect, but it does not explain parameter semantics, validation behavior, or what the response contains. Given the tool's moderate complexity (5 optional parameters, one with a special ADAPTIVE value), the description is adequate but leaves gaps that an agent would need to resolve.

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 only 20% (only scene_id has a description). The description lists the parameter concepts (printer, material, layer thickness, print setting) but does not add meaning beyond the schema's property names. It does not explain what values are valid for machine_type, material_code, print_setting, or layer_thickness_mm (e.g., the ADAPTIVE option is only in the schema, not the description). With low schema coverage, the description should compensate but does not.

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 ('Change') and resource ('a scene'), and enumerates the exact attributes that can be changed: printer, material, layer thickness, and print setting. It also explicitly notes that models are preserved, which distinguishes it from destructive scene operations like delete_scene or replace_model. This is a clear, specific purpose statement that differentiates the tool from siblings.

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 context: use this when you need to modify scene-level print parameters without affecting models. However, it does not explicitly state when NOT to use it or name alternatives (e.g., update_model for model-level changes, create_scene for new scenes). The 'while keeping its models' clause provides some context but no explicit exclusions or alternative routing.

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