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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful context beyond that: inheritance is resolved so audit reflects effective values, and the audit targets common failure causes rather than raw settings.

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 tight two-line description with the diagnostic purpose and target failure modes front-loaded. No filler or repetition of annotation 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?

An output schema exists, so return values need not be described. The main remaining gap is the single parameter's undocumented semantics; otherwise the description is sufficient for an agent to call 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?

Schema description coverage is 0%, so the description must compensate. It implies the single required `name` parameter is a process preset name, but gives no format, casing, or valid-value guidance.

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 (audit) and resource (a process preset), and adds that it examines EFFECTIVE values with inheritance resolved for specific failure modes. This distinguishes it reasonably from get_profile, though it never names that sibling explicitly.

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 listed failure symptoms (nozzle hitting infill, supports fusing, wall bulges), suggesting diagnostic use. However, it does not say when to use this instead of get_profile or list_profiles, nor any 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context beyond that — the accepted file formats (.stl, .obj, .3mf) and the metric units of the returned dimensions — though it says nothing about behavior on malformed or non-watertight files.

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 action, lists the formats inline, and enumerates return values without any filler. 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?

With an output schema present, the description needn't detail return structure, and rich annotations cover the safety profile; the format list and unit disclosure fill the main gaps. The only residual omission is path resolution semantics for the single required parameter.

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 partially does by listing supported file extensions, which constrains the file_path argument, but it never clarifies whether the path is absolute, relative to a workspace, or must reference an existing file. Meaningful but incomplete compensation.

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+resource pair ('Load a 3D model') and enumerates exactly what it returns (size in mm, volume, watertightness, face count). This clearly distinguishes it from siblings like scale_model or rotate_model, which modify rather than measure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the measurement/inspection tool, but nothing states when to prefer it over scale_model or rotate_model, nor any prerequisites (e.g. model must already exist). No exclusions or alternatives are named.

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 that this is a safe read operation. The description adds meaningful behavior beyond that: the default resolve_inheritance=true merges the 'inherits' chain up to the vendor preset, while false returns only overridden values. Error behavior for a nonexistent preset is not covered.

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, front-loaded with the core action and immediately followed by the inheritance semantics. No wasted wording; the longer second sentence earns its place by explaining the default behavior.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. The inheritance behavior is well covered, but the profile_type dimension and name-scoping semantics are left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains resolve_inheritance and its default well, but says nothing about 'name' (whether it is unique across profile types) or 'profile_type' (process/filament/machine) beyond what the enum already shows.

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 ('Get a preset's settings') and adds that it returns effective values by default. It doesn't explicitly contrast with siblings like list_profiles or audit_profile, and the 'preset' vs 'profile' terminology is slightly inconsistent.

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 clear guidance on the key decision: resolve_inheritance=true returns merged effective values, false returns only user overrides. It does not say when to prefer get_profile over list_profiles or audit_profile, so there is no exclusion or alternative routing.

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 cover the safety profile (readOnly, non-destructive, closed-world), so the description's added value is the 'newest first' ordering guarantee and the fact that only backups created by set_profile_parameter/restore_backup appear — real behavioral context beyond structured fields. It stops short of describing scoping or volume limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the action and resource, with the scoping and ordering facts appended. Nothing could be removed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the safety profile is covered by annotations. The remaining gap is the undocumented profile_type parameter and the underspecified 'name', which matter for calling the tool correctly in a family of profile tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, yet it only hints that 'name' is a preset name ('backups of a preset'). The profile_type enum (process/filament/machine, default process) is never mentioned, leaving an agent to guess whether it changes which backups are returned.

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 ('List backups of a preset') plus provenance (created by set_profile_parameter / restore_backup) and ordering ('newest first'), which distinguishes it from restore_backup and from the get_/list_profiles read tools. It does not explicitly frame itself against siblings, but the scope 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?

By naming set_profile_parameter and restore_backup as the producers, it implies the natural use case (find a backup before restoring), but it never states when to call this versus restore_backup or list_profiles, and gives no prerequisites or 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds the useful detail that each entry carries its inherited parent preset, but says nothing about ordering, completeness of the listing, or grouping beyond what the output schema will show.

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 well-formed sentence with the resource front-loaded and no filler. Every clause (categories, inherited preset) 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?

With an output schema present, the description need not explain return values, but it still mentions the inherited-preset field, which helps. Zero parameters and full annotation coverage mean the remaining obligations are small; only the relationship to get_profile is unaddressed.

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 takes zero parameters, which is the baseline-4 case. The description correctly conveys that no scoping arguments are involved, consistent with an empty input 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 verb (List) and a specific resource (the user's slicer presets), and enumerates the preset categories (process, filament, machine). It does not name a sibling such as get_profile to sharpen the boundary, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'List' naturally reads as the enumeration counterpart to get_profile. There is no explicit when-to-use or when-to-prefer-get_profile guidance, so an agent must infer the distinction from the verb 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 declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: the current state is snapshotted before the restore, which materially changes the risk calculus for the agent. It still doesn't say whether that pre-backup is retrievable or how errors surface.

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, zero filler, with the safety behavior front-loaded alongside the core action. Nothing to trim.

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?

An output schema exists and annotations cover the mutation semantics, so the description needn't explain return values. The one remaining hole is the undocumented profile_type enum and the meaning of 'name', which an agent must guess at before calling.

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% across three parameters, so the description must compensate. It does clarify backup_file's provenance (list_backups output), but 'name' is only implied to be the preset and the profile_type enum (process/filament/machine) is left entirely unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (restore) and resource (a preset from a backup file), and explicitly ties the backup_file input to list_backups, which distinguishes it from sibling reads. It stops short of differentiating from other mutating siblings like set_profile_parameter, but the resource scope 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 gives a clear ordering prerequisite: the backup file name must come from list_backups. That tells the agent when this tool is applicable, but it offers no explicit when-not guidance or note about what happens to the profile being restored over.

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 that the tool is non-read-only, idempotent, non-destructive, and closed-world. The description adds useful behavior beyond that: it writes to a new file and applies rotations in X, then Y, then Z order, which matters because rotation order affects the result. It still omits overwrite and file-format behavior.

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 well-structured sentence with the operation front-loaded. Every clause adds useful information: output behavior, rotation order, units, and intended purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values do not need to be explained, and annotations cover safety and idempotency. The description provides enough to call the tool with input/output paths and rotation angles, but omits file-format and overwrite constraints for a mutation that creates a new file.

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 clarifies the degrees and non-obvious X→Y→Z rotation order for the angle parameters, but it does not clarify file_path or output_path semantics such as accepted formats, overwrite behavior, or path requirements.

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 a 3D model into a new file. It also specifies rotation axes and order, clearly separating it from sibling operations such as scale_model and get_model_dimensions.

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 a clear intended use case: improving bed contact and reducing overhangs/supports. However, it does not explicitly state when not to use it or name alternatives such as scale_model when scaling would be more 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 idempotent=true, destructive=false and non-open-world, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: scaling is uniform (not per-axis) and the result goes to a separate output file, implying the source is preserved. It stops short of noting precision, units handling for target_height_mm, or error behavior when zero or multiple modes are supplied.

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, with the action front-loaded and the constraint clause immediately after. The examples are dense and each 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?

An output schema exists, so return values need not be described. The description covers purpose and the mutual-exclusivity rule that an agent would otherwise get wrong from a flat schema with three nullable fields. Minor missing pieces: units/axis clarification for target_height_mm and what happens on zero or multiple modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the load, and it does for the hard part: the three mutually exclusive scaling modes are explained with concrete examples (80 = 80%, 0.8 = 80%, target_height_mm = desired Z height) plus the exactly-one constraint. The two required path parameters (file_path, output_path) get no explanation, which is the only meaningful gap given self-evident names.

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 ('Scale a 3D model') plus two distinguishing qualifiers: uniform scaling and output to a new file. This cleanly separates it from the closest sibling, rotate_model, and from the inspection tool get_model_dimensions without requiring either 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 'pass exactly one of' clause gives selection rules among the three scaling parameters, which is useful, but there is no guidance on when to choose this tool over siblings (e.g. rotate_model, get_model_dimensions) or any preconditions. Usage is implied by the purpose 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 already declare this is a destructive, non-read-only, idempotent mutation. The description adds meaningful behavior beyond that: a backup is taken first, unknown keys are refused unless force=true, identity keys are refused, and list-shaped fields remain lists. These details materially improve the agent's ability to invoke it safely.

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 dense and front-loaded: it starts with the core action, then immediately covers backup behavior, value/list handling, typo refusal, and identity-key refusal. Every sentence adds operational value 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?

With an output schema present, return values need not be described, and the annotations cover the safety profile. However, for a 5-parameter mutation tool with 0% schema description coverage, the description leaves key parameter semantics undocumented, especially name, profile_type, and value representation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains key behavior, force behavior, and list handling, but it does not clarify the required name parameter, the profile_type enum values, or the expected value string format. The phrase 'Identity keys (name, inherits...)' could also be confused with the required name 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?

States a specific verb and resource: 'Set one setting in a user preset.' This clearly distinguishes mutation from read/list siblings, and it points to list_backups/restore_backup for backup-related actions. It does not explicitly contrast with get_profile or audit_profile, so it is clear but not fully sibling-differentiating.

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 it by saying it sets one setting and that backups are taken first, and it gives a concrete force=true path for unknown keys. However, it does not explicitly state when to use this versus get_profile, audit_profile, or restore_backup beyond the backup reference.

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