SimplyPrint: 3D Print Farm Management

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

Annotations indicate this is a write operation (readOnlyHint: false) with no special safety flags. The description adds one useful behavioral limitation: 'File attachments are not supported via MCP.' However, it does not disclose whether both file_id and item_id can be provided, whether comments are appended or replaced, or any authentication requirements, so behavioral disclosure is minimal.

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 totaling 27 words. The first sentence is front-loaded with the action and target, and the second sentence provides a key limitation. No waste.

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 has 4 parameters, no output schema, and minimal annotations, so the description must carry the burden. It covers the basic purpose and one limitation but does not explain parameter relationships, required fields, or return values. For a tool with this complexity, the description leaves significant ambiguities that could lead to incorrect invocations.

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 schema description coverage at 0%, the description must clarify the parameters. It partially does so: 'general or feedback' suggests values for 'type', and 'queue item or user file' identifies the targets for 'item_id' and 'file_id'. However, it does not explicitly map parameters to these concepts, nor does it explain the 'comment' field or whether targets are mutually exclusive, leaving ambiguity for a 4-parameter tool.

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 function: 'Add a comment (general or feedback) to a queue item or user file.' The verb 'Add' and the target resources distinguish it from sibling tools like update_queue_comment, delete_queue_comment, and list_queue_comments. The mention of 'general or feedback' also indicates comment types, adding specificity.

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 adding comments but provides no explicit guidance on when to use this tool versus updating or deleting comments, nor does it name alternatives. The lack of exclusions or prerequisites is a clear gap, though the context of 'queue item or user file' gives some situational 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?

The annotations provide no positive hints (all flags are false), so the description must disclose behavioral traits. It does mention the 'pick exactly one' rule and custom field support, but omits side effects, error behavior, prerequisites, and outcome. For a mutation tool, this is a significant 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?

The description is two sentences, front-loaded with the core action, and every phrase adds value. No redundant or ambiguous 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?

With 10 parameters, no required fields in the schema, and no output schema, the description should provide more context. It doesn't explain what happens if no file source is given, whether a queue item is created immediately, or what the response contains. The implied requirement of 'exactly one file source' conflicts with the schema's empty required array, leaving the agent uncertain about validation.

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?

While schema coverage is 60% and many params have descriptions, the description adds critical meaning beyond the schema, especially for fileId (hex hash from upload endpoint), filesystem (UserFile.uid), and the exact structure of custom_fields. It compensates well for the most important params, though it leaves tags and for_* params untouched.

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 and resource ('Queue a file for printing') and further differentiates the tool by naming the two accepted file sources. This clearly distinguishes it from siblings like add_queue_comment or create_print_job.

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?

Provides explicit guidance on selecting between fileId and filesystem as the file source, and mentions support for PRINT_QUEUE custom fields. However, it does not name alternative tools or explicitly state when to use this tool over a sibling like create_print_job, so it's not 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 convey that this is a mutating operation (readOnlyHint=false, destructiveHint=false). The description adds the meaning of 'remaining weight' and the manual weighing context, but does not disclose side effects like whether the empty spool weight is saved or how existing values are overwritten.

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, but it is under-specified for a tool with 7 parameters. It is concise but sacrifices necessary detail.

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 no output schema and several interacting parameters, the description is inadequate. It does not explain parameter combinations, prerequisites, return values, or side effects, making it difficult to understand how to correctly invoke the 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?

With only 14% schema description coverage, the description should compensate by explaining how to specify the weight (e.g., via percent_left, grams_remaining, or weighed_gross and subtract_empty_spool). It does not, leaving the 6 undocumented parameters ambiguous.

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 ('Adjust the remaining weight') and resource ('filament spool'), with a concrete use case ('after manual weighing'). It is distinct from sibling tools like assign_filament or mark_filament_dried, though it doesn't explicitly name 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?

The phrase 'e.g. after manual weighing' implies a specific scenario, but there is no explicit guidance on when to use this tool vs alternatives, nor any exclusion criteria. The context is helpful but not fully developed.

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 write operation (readOnlyHint=false) and non-destructive behavior. The description adds valuable context: it can process multiple items and accept an optional comment, providing insight into the operation's scope and side effects. 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?

The description is a single, front-loaded sentence that conveys the action, scope, and option in a compact manner. No redundant words or filler, making it easy to parse.

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 3 undocumented parameters and no output schema, the description is too sparse. It fails to explain how to specify which items to approve or what the return value represents, making it incomplete for reliable invocation.

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

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

Schema description coverage is 0%, and the description only mentions 'optional comment' without explaining the 'job' or 'jobs' fields. It does not clarify that these are identifiers, how 'jobs' is formatted, or whether 'job' and 'jobs' are mutually exclusive or aliases, leaving significant ambiguity.

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 ('Approve') with a clear resource ('queue items') and scope ('pending/revision/denied'), plus batching ('one or more'). This clearly distinguishes it from sibling tools like deny_queue_item and send_back_for_revision.

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 conveys when to use the tool: to approve queue items in specific states. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it over similar 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 indicate non-read-only, non-destructive, non-idempotent behavior. The description adds context by explaining the concrete effect (hiding from default history listings), which goes beyond the bare 'Archive' verb and provides useful behavioral detail without contradicting 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?

The description is a single, focused sentence that immediately communicates the tool's purpose and effect. No unnecessary words 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 simple mutation tool with no output schema, the description covers the core behavior but omits details like the ability to archive multiple jobs, the optional reason field, and reversibility (though the sibling 'unarchive_print_job' hints at it). It is minimally adequate but leaves some gaps.

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

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

Schema description coverage is 0%, and the description provides no explanation of the 'jobs' array or 'reason' parameter. The description says 'a print job' singular while the schema expects an array, potentially confusing. The agent gets no additional meaning beyond the parameter names and types.

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 ('Archive') and the target resource ('print job'), and the parenthetical clarifies the effect: 'hide from default history listings'. This distinguishes it from siblings like 'unarchive_print_job' and other queue actions.

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 use case via the parenthetical 'hide from default history listings', but it does not explicitly mention when to use versus alternatives, nor does it state exclusions or prerequisites. The context is clear but not elaborated.

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 this is a mutation (readOnlyHint: false) but provide no further safety details. The description adds only the nuance about targeting an extruder slot; it does not disclose consequences like overwriting existing assignments or side effects of the 'source' parameter.

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 concise sentence that front-loads the core purpose. Every word is necessary and there is 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?

With 4 parameters, no output schema, and no explanatory detail on source or extruder, the description is too minimal. It does not inform the agent about required context fields or what the operation returns, making it incomplete for a tool with this complexity.

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 50%, and the description does not compensate. It mentions 'printer' and 'extruder slot' but not the 'source' or 'extruder' parameters. The filament_id description is confusing, as its schema type is integer but it says 'comma-separated for multiple'.

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 ('Assign') with a clear resource ('filament spool') and target ('printer (or a specific extruder slot)'). It clearly distinguishes from sibling tools like unassign_filament and adjust_filament_weight.

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 this tool - when you need to assign a filament to a printer. However, it does not explicitly mention alternatives or exclusions, such as using unassign_filament to remove assignments, so guidance is implied rather than 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 declare destructiveHint=true and readOnlyHint=false, but the description adds no further behavioral context. It does not mention irreversibility, possible return-to-queue behavior (though schema hints at it), or other side effects, leaving the agent unaware of consequences beyond the basic action.

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, clear sentence with no filler or redundancy. It is appropriately sized for a tool whose schema already provides detailed parameter 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 six parameters, no output schema, and a destructive action, the description is significantly under-specified. It does not explain how cancellation affects the print job, when reason/comment might be required, or the implications of return_to_queue, making it incomplete for an agent to fully understand 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 100%, so all six parameters are already documented with descriptions. The tool description itself does not add any parameter meaning, so 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 clearly states the action ('Cancel') and the target ('the current print on a printer'), which distinguishes it from siblings like pause_print or archive_print_job. It uses a specific verb and resource, making the tool's intent immediately obvious.

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 provided on when to use this tool versus alternatives such as pause_print or delete_queue_item. It does not mention prerequisites, exclusions, or scenarios where another tool might 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?

The description discloses that the tool can edit existing folders and set org-level permissions, which is useful. However, it doesn't detail side effects, authentication requirements, or behavior on conflicts. Annotations provide no safety hints, so the description carries the burden but only partially meets 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?

One concise sentence that front-loads the core purpose. 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?

For a 5-parameter create/edit tool with no output schema, the description is too thin. It doesn't explain parameters, edit semantics, or return values, making it incomplete for an agent to invoke 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 0% schema description coverage, the description should explain parameters, but it only vaguely references 'org-level permissions.' It doesn't clarify the roles of name, parent_folder, item_id, or org_perms, leaving the schema to carry the semantic load.

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 function with a specific verb ('Create') and resource ('folder'), and also notes the edit capability. This distinguishes it from sibling tools like delete_folder or move_folder.

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 creating or editing folders but does not explicitly state when to use it over alternatives or exclude cases. An agent can infer its purpose, but there's no explicit 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 only provide readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the description must carry the behavioral burden. It discloses important traits: auto-start behavior based on autostartPrints, deduplication across printers for next_queue_item, and the operational requirement for printer_id. This adds meaningful context 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?

The description is three sentences covering the core action, file source alternatives, custom field support, and autostart behavior. It is dense with information but well-organized, with no filler or redundant repetition of what the schema already provides. 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 complex 10-parameter mutation tool with no output schema and minimal annotations, the description covers the main execution modes, printer constraints, and auto-start behavior. It omits advanced parameters like mms_map and start_options and does not specify return values, but it is reasonably complete for typical usage scenarios.

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 80%, so the baseline is 3. The description adds value by enumerating the file source semantics and explicitly stating the mutual exclusivity condition, complementing the per-parameter schema descriptions. However, parameters mms_map and start_options remain undocumented in both the description and schema, leaving a minor 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 clearly states 'Start a print job on one or more printers' with a specific verb and resource. It goes further to enumerate the distinct file source options (file_id, filesystem, queue_file, reprint, next_queue_item), which distinguishes it from sibling tools like add_to_queue and cancel_print. This is a precise, unambiguous statement of 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 explicitly explains the 'exactly one of' file source alternatives and notes mutual exclusivity for next_queue_item. Schema descriptions add 'Choose this when' guidance for file_id, filesystem, and queue_file. However, it does not directly contrast with sibling tools like add_to_queue, so the when-not-to-use context is partially missing.

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 and readOnlyHint=false, covering the safety profile. The description adds the nuance of 'one or more' files but does not disclose permanence, trash behavior, or side effects on printer assignments. With annotations present, the added context is minimal.

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 with no fluff, front-loading the action. Every word earns its place for a simple tool.

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?

As a destructive operation with one parameter and no output schema, the description should explain return behavior, irreversibility, or effects on related entities (e.g., files referenced by print jobs). It omits these, leaving significant gaps for an agent to reason about.

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% with a single string parameter 'file' having no description. The phrase 'one or more' is ambiguous given a single string parameter—it could imply multiple invocations, a list, or a path pattern. The description does not clarify the expected format (e.g., path vs ID), failing to compensate for the schema's 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?

'Delete one or more files.' uses a specific verb and resource, clearly distinguishing it from siblings like delete_folder, move_file, and update_file. The scope ('one or more') adds clarity.

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 (when you need to delete files) but does not explicitly state when to use it versus alternatives or mention exclusions. The sibling names make the context clear, but no direct guidance 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?

The annotations already declare destructiveHint=true, so the description's 'Delete' adds no new safety information. It does add a small behavioral nuance ('one or more folders') but fails to disclose whether deletion is recursive, whether folders must be empty, or any effects on child items. Given the annotation covers destructiveness, this minimal addition earns a low score.

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 five-word sentence with no fluff. It is immediately clear and front-loaded with the action. Every word adds essential meaning; 'one or more' is a concise scope qualifier.

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 action with no output schema, this description is too thin. It does not clarify whether deletion is recursive, whether empty folders are required, or how errors are handled. The annotation covers destructiveness, but the agent still lacks enough context to safely invoke the tool in many real-world scenarios.

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%, and the description does not compensate. It repeats 'folders' but never explains what the 'folder' parameter should contain (path? ID? comma-separated list?). The 'one or more' phrasing hints at multiplicity but gives no syntax. This is a critical gap for successful invocation.

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 ('Delete') on a specific resource ('folders'), and it names the singular sibling tool 'delete_file' by contrast. It also conveys multi-target capability with 'one or more', which adds useful scope. This effectively distinguishes it from related tools like create_folder and move_folder.

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 about when to use this tool versus alternatives such as delete_file or empty_queue. No prerequisites, exclusions, or mention of context in which deletion is appropriate. The description only states what it does, not when to choose 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 declare destructiveHint=true, so the description adds value by explaining the authorship/permission requirement and specifying the target as an 'approval comment.' This is context beyond the schema and 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 one sentence, front-loaded with the verb 'Delete,' and contains no wasteful wording. Each word adds meaning, making it highly concise and well-structured.

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 delete tool with one parameter and no output schema, the description covers destructive behavior and permission context. However, the lack of clarification that item_id is the comment ID is a significant gap that could lead to misidentification of the target. A brief parameter explanation would make it 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 only parameter, item_id, is a required integer with no schema description (0% coverage). The description never explains that item_id refers to the comment ID, leaving the agent to infer from the tool name. Since schema coverage is low, the description should have compensated but did 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 clearly states the tool deletes an approval comment, with a specific scope: 'you authored (or any comment if you have the permission).' This distinguishes it from sibling comment tools like add_queue_comment, update_queue_comment, and list_queue_comments.

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 (deleting a comment) but does not explicitly mention when to use this over update_queue_comment or when not to use it. The permission note provides context, but there is no explicit comparison to alternatives.

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?

With annotations already indicating destructiveHint=true and readOnlyHint=false, the description adds some behavioral context by explaining that items can be moved to another group via move_to. However, it does not state what happens to the items if move_to is not provided (whether they are deleted as well), which is a significant gap for a destructive 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 extremely concise: two sentences, front-loaded with the main purpose and a clear optional modifier. Every word earns its place, and there is no redundancy or irrelevant detail.

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 delete operation, the description covers the core action and optional move behavior. However, it omits important context such as the fate of items when move_to is absent, the exact meaning of item_id, and any prerequisites or side effects. Given the availability of destructive annotations and the simple operation, 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?

The description explicitly explains the move_to parameter's function, but it does not clarify that item_id represents the queue group identifier. Given 0% schema description coverage, the description should compensate by defining both parameters. The critical item_id parameter remains ambiguous.

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 function with a specific verb ('Delete') and resource ('queue group'), distinguishing it from sibling tools like save_queue_group, reorder_queue_group, and list_queue_groups. The optional move_to behavior is also mentioned, further clarifying 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 implies usage: delete a queue group when it is no longer needed. However, it does not explicitly state when to use this tool versus alternatives (e.g., empty_queue for removing items, delete_folder for folders). No exclusions or contrasting guidance are provided, so the guidance is minimal but not misleading.

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 and readOnlyHint: false. The description adds behavioral context by noting that denial can either remove the item or request revisions, and that a comment is required. This goes beyond what annotations alone convey and 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?

The description is a single sentence, front-loaded with the active verb and resource, and contains no fluff. Every phrase 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 destructive tool with four optional parameters and no output schema, the description leaves ambiguity about the use of 'remove' versus 'request revisions,' and does not clarify job identifiers. It also omits post-denial behavior or reversibility. More detail is needed for safe and correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that 'comment' should explain the decision and hints at 'remove' via 'removing it,' but it does not explain the 'job' vs. 'jobs' parameters or how to indicate whether to remove versus request revisions. This is insufficient for a four-parameter tool with no parameter-level 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 clearly states the action—'Deny a pending queue item'—and specifies two possible outcomes: removing it or requesting revisions. This distinguishes the tool from siblings like approve_queue_item and gives a specific resource (pending queue item).

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 case is clear from the verb 'deny' and the mention of 'pending queue item,' but the description does not explicitly compare with alternatives such as approve_queue_item, send_back_for_revision, or remove_from_queue. Usage context is implied rather than explicitly described.

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 set destructiveHint=true, but the description goes further by explicitly warning 'DESTRUCTIVE', detailing what is deleted (all items, optionally filtered), and adding the user-confirmation requirement. This is valuable context beyond the annotation.

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 concise, front-loaded sentences. Every word earns its place, starting with the crucial 'DESTRUCTIVE' warning, followed by the action and the safety confirmation.

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 destructive tool with two optional parameters and no output schema, the description covers purpose, parameter semantics, and the key safety requirement. It is complete enough for an agent to invoke 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 schema description coverage at 0%, the description explains both parameters: 'group' and 'done-only' as optional filters. This adds meaning beyond the raw schema, though it does not elaborate on what 'group' refers to in detail.

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 'Delete all items from the queue' with a specific verb and resource. It distinguishes itself from per-item queue tools like remove_from_queue by indicating bulk deletion, and optional filters for group or done-only provide clear 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?

It provides clear context for when to use the tool (deleting all or filtered items) and explicitly instructs 'Confirm with the user before calling.' It does not explicitly name alternative tools for individual removal, but the scope is implicit 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, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds that the estimate can be scoped to a specific printer, which is some context beyond annotations, but it does not explain return format, dependencies, or limitations.

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 concise sentence that is front-loaded with the core action. Every word earns its place, and there is no unnecessary fluff 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?

With 5 undocumented parameters and no output schema, the description is too minimal. It fails to explain what each parameter means, what the estimate is based on, or what kind of result the agent should expect, making it incomplete for a tool of this complexity.

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%, and the description only hints at printer_id ('optionally for a specific printer'). The other parameters (item_id, mms_map, newFile, analysis) remain entirely unexplained, leaving the agent without necessary semantic understanding.

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 estimates the print cost of a file, optionally for a specific printer. The verb 'estimate' and resource 'file cost' are specific, and the optional printer parameter distinguishes it from sibling tools like get_queue_item_cost.

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 on when to use this tool versus alternatives. It does not mention when to choose estimate_file_cost over get_queue_item_cost or other costing-related tools, nor does it state any prerequisites or use cases.

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 idempotentHint=true, so the safety profile is covered. The description adds useful context about the included metrics and optional filters, but does not disclose default behavior (e.g., whether unfiltered calls return all account data) or return format. This is adequate but not rich behavioral context beyond what annotations provide.

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, compact sentence that front-loads the core purpose and then mentions optional filters. It is appropriately sized with no wasted words, making it easy to parse and process.

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 7 parameters and no output schema, the description does a reasonable job by listing the returned metrics, but it omits details about the meaning of several parameters and any default behavior. For a statistics tool with moderate complexity, the description is adequate but leaves room for clarification around filter semantics and response structure.

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%, and the description only partially compensates by mentioning 'date range and user/printer filters', which vaguely maps to start_date, end_date, users, and printers. However, parameters like 'general', 'fake_data', and 'printer_models' are left completely unexplained, leaving significant gaps for agent understanding.

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 the tool's purpose as providing account-level print statistics, listing specific metrics (success rate, filament used, print time, cost) and optional filters. It effectively distinguishes this from sibling tools like get_farm_overview or get_referral_stats by specifying the account scope and metric types, though it lacks an explicit verb like 'retrieve' or 'get'.

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 indicates the optional date range and user/printer filters, implying it is used for filtering statistics, but provides no explicit guidance on when to choose this tool over alternatives. There is no mention of exclusions or when not to use it, and sibling tools like get_farm_overview are not referenced for comparison.

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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral semantics beyond this, such as defining each bucket (e.g., 'awaiting_bed_clear' means a print finished but bed not cleared) and explicitly noting that 'Counts overlap intentionally' (e.g., a printer can be in 'online' + 'printing' + 'ai_running'). This transparency helps the agent understand the nuanced state model.

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 paragraph that is quite long due to the need to define many buckets. However, every sentence serves a purpose: the opening sentence states the primary use, the middle lists all buckets, and the closing sentence clarifies the overlap semantics. It is front-loaded with the core purpose. It earns its length given the tool's complexity, though it could be broken into a list for readability.

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

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

With no output schema present, the description must explain what the tool returns, and it does so thoroughly. It specifies a top-level total and a {count, printers:[{id,name}]} structure per bucket, and enumerates every bucket with appropriate definitions. It also explains the intentional overlap, making the return semantics fully self-contained.

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 zero parameters (properties: {}), so schema coverage is 100% trivially. There are no parameters to explain. The description doesn't discuss parameters, which is appropriate. Per the rubric, a baseline of 4 is given for 0-param tools, and the description uses this opportunity to explain the output structure instead, which is helpful.

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 function: 'One-shot summary of farm-wide printer state.' It uses a specific verb ('get') and resource ('farm overview'), and distinguishes itself from the sibling tool 'list_printers' by explicitly saying 'Use this (NOT list_printers)'. The list of buckets further clarifies what the summary includes.

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 tells when to use the tool: 'when the user asks "how many printers are printing/idle/awaiting bed clear/etc." or "what is the state of the farm"'. It also names the alternative (list_printers) and explains why NOT to use it for these queries. This is clear usage 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the two accepted ID types (spool_id and spool_short_id) and the format of the short ID. However, it does not disclose behavior when neither ID is provided, or what 'details' are returned, leaving some gaps beyond 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 three sentences long and front-loads the core purpose. It conveys essential ID semantics with examples ('T2SO', 'M0WT') without unnecessary fluff. It could be slightly more compact, but 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 tool has 5 parameters with no schema descriptions and no output schema, so the description carries a heavy burden. It does not explain the optional parameters, the return value structure, or the behavior when no filter is provided. For a tool with this complexity, the description is incomplete and leaves too much for the agent to infer.

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 must compensate for explaining all parameters. It explains spool_id and spool_short_id in detail, but ignores the other three parameters (public, company_id, locationscount), which are non-obvious boolean and integer fields. The description covers less than half of the parameters, leaving significant ambiguity.

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: 'Get details of one specific filament spool.' It clearly distinguishes itself from the sibling list_filaments by explicitly stating 'Use this (NOT list_filaments+grep) when the user names a spool by id or short id.' This precisely identifies the tool's purpose and its unique 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 explicit usage direction: use this tool when the user names a spool by id or short id, and explicitly warns against the alternative (list_filaments+grep). This provides clear when-to-use and when-not-to-use guidance, naming the alternative directly.

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, idempotentHint, and destructiveHint. The description adds no additional behavioral context such as what constitutes 'usage history,' whether pagination is supported, or how results are ordered. It merely restates the read-only nature of the 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 concise sentence with no waste. However, it is under-specified: brevity comes at the cost of detail. It is not badly structured, but it is minimal.

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 5 parameters, no output schema, and zero schema coverage, the description should explain purpose, filters, and return data. It only states the basic action, leaving the agent to guess about pagination, scope, and the meaning of 'usage history.'

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 for 5 undocumented parameters. It only hints that 'filament spool' may map to item_id, but provides no explanation of page, perPage, public, or user_id. This is inadequate for invoking the tool correctly.

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

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

The description uses a specific verb 'Retrieve' and identifies the resource as 'usage history of a filament spool,' clearly distinguishing it from sibling tools like get_filament or list_filaments. The name and description align.

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 provided on when to use this tool versus alternatives such as get_filament or list_filaments. There are no prerequisites, exclusions, or context about which scenarios call for history retrieval.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that permissions are included in the response, which is useful, but it does not disclose other behavioral aspects like error handling, response structure, or required authentication. Since annotations cover the main safety attributes, a mid-range score 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?

The description is a single, information-dense sentence: 'Get a folder's details including permissions.' Every word contributes to the meaning, with no filler or repetition. It is front-loaded and appropriately sized for the simplicity of the tool.

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 strong annotations, the description is minimally sufficient. It states the core purpose and highlights permissions, but does not describe the full return value (given no output schema) or any edge-case behavior. It could benefit from a bit more detail about what 'details' includes, but overall it is adequate.

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 has 0% description coverage, and the description does not explain item_id. While the parameter's purpose is somewhat inferable from the tool name and schema (integer, minimum 1), the description fails to explicitly state that item_id is the folder ID or to give any additional semantic meaning. With no description coverage, the tool should compensate; it 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 uses the specific verb 'get' and clearly identifies the resource ('a folder's details'), and the phrase 'including permissions' clarifies what kind of details are returned. This distinguishes it from sibling tools like create_folder, delete_folder, and get_printer/get_print_job, which target different actions or resources.

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 usage is implied by the name and description: when you need details of a specific folder. However, it does not explicitly mention when not to use it or point to alternatives (e.g., listing files or folders), nor does it provide context about prerequisites like needing an item_id. Thus, it provides adequate but not explicit 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, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context by enumerating the data domains covered, but does not disclose aggregation, pagination, or the exact shape of the overview beyond the listed categories.

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, tightly written sentence that front-loads the resource and lists the key content areas. Every word adds value, and 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?

With no output schema, the description must indicate what the tool returns. The sentence provides a useful enumeration of the dashboard's components, but 'overview' is slightly vague (counts vs. lists vs. statuses). Still, for a simple read-only getter with no params, this is sufficiently complete for an agent to understand the tool's purpose and output.

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% (empty schema). Per the rubric, 0 params gives a baseline of 4; the description correctly adds no parameter information because none exists.

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 names the resource ('maintenance dashboard') and specifies the content areas (maintenance jobs, problems, inventory, printer maintenance status). It is distinct from siblings like get_farm_overview or list_print_jobs, though it doesn't explicitly contrast itself.

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. Siblings like get_farm_overview or list_print_jobs exist, but the description does not indicate whether this is a high-level summary or when to prefer it over detailed list 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 known. The description adds the 'compatibility matcher' context, but does not disclose return format, whether multiple items may be returned, or how parameters affect behavior. Minimal value beyond 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 sentence, direct and front-loaded, with no redundant or filler content. It efficiently conveys the core 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?

For a tool with 12 parameters, no output schema, and low parameter documentation, the description is far too sparse. It does not explain return values, matching algorithm behavior, or parameter usage, making it difficult for an agent to confidently invoke the tool with correct options.

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% (compact and printer_id have descriptions), leaving 10 parameters undocumented. The description adds no parameter information whatsoever, failing to compensate for the low coverage. Parameters like filters, sorting, settings, and deselects remain completely ambiguous.

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 finds best-matching queue items for printers using a compatibility matcher, which is a specific verb and resource. However, it does not distinguish this tool from the similarly named sibling get_next_queue_items_for_printers, so it falls short of a 5.

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

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

The description implies usage—when you need to match queue items to printers—but provides no explicit guidance on when to use this tool versus alternatives like get_next_queue_items_for_printers or list_queue. No exclusions or alternative tool references are given.

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 idempotentHint=true, which the description reinforces. It adds valuable context beyond annotations: the dedup guarantee that the same queue item is never returned twice across printers, and the inclusion of match failures per printer. This is useful behavioral detail for a safe, idempotent 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, front-loaded with the essential action 'Read-only preview', and no filler. Every sentence adds value: what it does, the dedup behavior, and the failure reporting.

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 only 2 params, no output schema, and clear annotations, the description covers the core behavior, important edge cases (offline printers, dedup), and the purpose of the returned issues. It is self-contained enough for an agent to select and invoke 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 coverage is 100% with detailed parameter descriptions, so baseline is 3. The description adds extra context by explaining that printer_id accepts offline printers and that they return their would-be match, which is useful semantics not present 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?

Description opens with 'Read-only preview' and clearly states the tool returns the next queue item that would be started for each given printer. It distinguishes from siblings like get_next_queue_item by explicitly mentioning batch processing across printers and the dedup matcher.

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 clearly implies a preview use-case ('Read-only preview', 'Does NOT start any job') and suggests a purpose ('so you can explain why a printer has nothing to print'). However, it does not explicitly name alternatives like the singular get_next_queue_item or state 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 declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by enumerating the data categories returned and noting the compact default is tuned for AI context. It doesn't contradict annotations and provides useful behavioral context beyond the structured fields.

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 pack a clear verb, resource, scope, usage examples, and an alternative. Every word earns its place, with no fluff 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 simple get-by-id tool with strong annotations and a schema explaining compact, the description covers what data it returns, when to use it, and why it's preferable. No output schema is present, but the description lists key return categories, making it sufficiently complete for an agent to invoke 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?

Schema coverage is 50%: compact is well-described, printer_id only has type. The description says 'by id' which clarifies printer_id's role, and 'Cheaper and less noisy' reinforces why compact defaults to true. However, it doesn't add new meaning for printer_id beyond what the schema implies, leaving that parameter semantically thin.

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 gets details, status, temps, current job, filament, and notifications for one specific printer by id. It explicitly distinguishes itself from list_printers, making its purpose 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?

It gives explicit when-to-use guidance: whenever the user asks about a single printer they've already identified, with concrete examples. It also names the alternative (list_printers) and explains why this tool is preferred (cheaper, less noisy).

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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds little beyond that, merely noting 'detailed info' without explaining return format or any edge-case behavior. No contradiction 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 clear sentence, front-loaded with the main action and resource. Every word adds value, and there is 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?

Despite being a simple read tool with good annotations, the description lacks critical context about parameter semantics and return value details. With no output schema and 0% parameter coverage, the agent is left with ambiguous parameters and an under-specified notion of 'detailed info'. The description is too sparse to be considered 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%, leaving all three parameters (extra, item_id, getcustomfields) undocumented. The description only implies that item_id identifies the specific print job, but does not explain the meaning or purpose of extra or getcustomfields, failing to compensate for the lack of 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 'Get detailed info for a specific print job' clearly specifies the verb (get), the resource (print job), and the scope (specific vs. list). It distinguishes itself from sibling tools like list_print_jobs by emphasizing 'specific' and 'detailed info', making its purpose 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 for retrieving details of a single print job, but does not explicitly state when to use it compared to alternatives like list_print_jobs or get_queue_item. No exclusions or alternative references are provided, so guidance is only implied.

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, idempotentHint=true, and destructiveHint=false, ensuring the agent knows this is a safe, side-effect-free read. The description adds minimal behavioral context, only clarifying the target is a single known item, with no extra information on return format or error 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 entire description is a single seven-word sentence, directly front-loaded with the action and subject. There is no wasted wording or filler, making it highly concise.

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?

Despite rich annotations, the description fails to specify what 'details' includes—whether it returns cost, comments, filament data, or other related fields. Without an output schema, the agent cannot predict the return structure, and the presence of overlapping sibling tools like get_queue_item_cost heightens the 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?

The schema defines a single required integer 'item_id' with no description (0% coverage). The description's phrase 'specific queue item' implies the parameter identifies the item, but it does not explain where the ID comes from or any constraints, offering only marginal value beyond the schema's clear property name.

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 ('Get') and resource ('details of a specific queue item'), clearly distinguishing this from list_queue, get_next_queue_item, and get_queue_item_cost by focusing on a single, identified queue item. It states the primary action unambiguously.

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 information is provided about when to use this tool versus alternatives such as list_queue or get_next_queue_item. The description only states what it does, not the appropriate context or exclusions, leaving the agent without selection 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?

The description adds no behavioral context beyond the annotations, which already declare the tool read-only, idempotent, and non-destructive. Since annotations cover the safety profile, the description is not contradictory but also provides no extra context like return format or computational assumptions.

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 clear sentence that efficiently conveys the core purpose and an optional variant. No filler or redundant information is present.

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 four parameters, no output schema, and zero schema descriptions, the description is too sparse to be fully useful. It does not explain the role of 'mms_map' or the difference between 'item_id' and 'queue_item_id', leaving the agent to guess or probe.

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 schema description coverage at 0%, the description must compensate for undocumented parameters. It only hints at 'printer_id' via 'optionally for a specific printer' but leaves 'item_id', 'mms_map', and the required 'queue_item_id' unexplained, which is a significant gap for a tool with four 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 uses a specific verb ('Calculate') and resource ('estimated cost of a queue item'), clearly distinguishing it from sibling tools like 'estimate_file_cost' or 'get_queue_item'. The optional printer specificity also aligns with one parameter, making the purpose 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?

No explicit guidance is given on when to use this tool versus alternatives. The description implies usage for queue item cost estimation but does not mention exclusions, prerequisites, or when to choose a different tool like 'estimate_file_cost' or 'get_queue_item'.

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 readOnly, idempotent, and non-destructive behavior. The description adds domain context (what statistics are included) but does not disclose additional behavioral traits such as data freshness, authentication requirements, or aggregation behavior. Some value is added, but it is limited.

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, compact phrase that front-loads the resource name and lists the key metrics. Every word earns its place; there is no waste 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 simple, parameterless getter with no output schema, the description adequately indicates return values (conversions, earnings, pending payout). It could be more explicit about the return structure (e.g., an object), but it is complete enough for this simplicity level.

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 parameter semantics, and there is no schema to compensate for; the description's mention of statistics content is sufficient.

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 the resource (referral program statistics) and specifies key metrics (conversions, earnings, pending payout). It is distinct from any sibling tools, though it lacks an explicit verb like 'get' or 'retrieve'.

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 like get_account_statistics or get_farm_overview. There are no exclusions or prerequisites mentioned, leaving the user to infer usage solely from the name.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. However, the description adds no additional behavioral context, such as what is returned, whether the file must exist, or what happens if no slicer settings are stored. The description contributes no extra 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?

The description is a single, front-loaded sentence with no filler. It conveys the core purpose efficiently and is appropriately sized for such a simple tool.

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

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

Given the tool's simplicity (one parameter, read-only, no output schema), the description provides a basic but sufficient understanding of the tool's purpose. However, it lacks any detail about the return value, potential error conditions, or whether settings are always present. A bit more context would improve completeness, but it is not critically deficient.

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% for the 'file' parameter. The description only restates that the tool acts on 'a file', which maps directly to the parameter name. It does not clarify whether 'file' is a file ID, path, or other identifier, nor does it explain any constraints or formats. The description fails to compensate for the lack of schema documentation.

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 ('Retrieve') and the specific resource ('slicer settings stored for a file'). This distinguishes it from sibling tools that handle printers, queue items, or filament. It is a precise and unambiguous statement of the tool's function.

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 provided about when to use this tool versus alternatives. The description simply states what it does, without any context about use cases, prerequisites, or when to prefer it over other get/list tools. There is no mention of exclusions or alternative 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, idempotentHint, and destructiveHint false. The description adds valuable behavioral context by disclosing a fallback to synthetic data when no applicable entity exists, which goes beyond 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: purpose, target users, and fallback behavior. No fluff, front-loaded with the core action.

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 purpose, use case, and fallback, but misses explanations for 'limit' and 'version' parameters and does not describe the return payload structure (no output schema exists). Gaps exist for an effective tool description.

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 explain parameters. It only implies that 'event' selects the event type, but gives no detail on 'limit' or 'version'. The parameter names are self-explanatory, but the description adds minimal semantic value.

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 retrieves realistic sample webhook payloads for a specific event type, matching live delivery envelopes. This specific verb+resource combination distinguishes it from sibling tools that perform actual operations on print jobs, queues, and filaments.

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: integration platforms need to show payload shape before real events fire. It does not explicitly name alternatives or when-not conditions, but the context is strong enough to guide selection.

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 adds value by explaining the behavior 'move to origin position', which goes beyond the annotation's readOnlyHint=false. However, it doesn't mention potential safety concerns (e.g., obstructions) or effect on ongoing operations, so it only partially discloses behavioral context.

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 sentence that is concise and to the point. Every word contributes to explaining the tool's purpose, with no unnecessary 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 simple tool with full schema coverage, the description is minimally sufficient, but it lacks context about when homing is appropriate or any prerequisites. The optional snippet_id parameter is not explained in the description, and no mention is made of potential side effects.

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 already provides 100% coverage with descriptions for all three parameters (axes, printer_id, snippet_id). The tool description doesn't add any parameter-specific details, so it relies on the schema, which is adequate.

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 action ('home') and resource ('printer axes'), and clarifies what homing means ('move to origin position'). It is specific enough to distinguish from move_printer_axis, though it doesn't explicitly call out that difference.

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 provided on when to use this tool versus siblings like move_printer_axis or send_gcode. It doesn't mention prerequisites such as the printer being idle or that homing should be done before printing.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the diagnostic matching/missing purpose but does not disclose details like return format or how the 'why' is determined, which would have added more 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 consists of two concise, front-loaded sentences. The first states the action and scope; the second gives the use case. 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?

The tool has no output schema, so the description carries the burden of explaining what the tool does. It conveys the core diagnostic purpose well, but the unexplained 'mode' parameter and vague 'why' leave some gaps for the agent to fully understand the tool's behavior.

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 only mentions 'a specific printer' (printer_id) but entirely ignores the optional 'mode' parameter, leaving its enum value 'autoprint' unexplained. This is a notable gap for a tool with only 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 uses the specific verb 'Show' and resource 'queue items' with a clear scope ('match/miss a specific printer' and 'why'), which clearly distinguishes it from sibling tools like get_queue_item or list_queue. It immediately conveys the tool's diagnostic function.

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 use context: 'diagnosing why a queue item will not print.' This implies when to use this tool over others, though it does not explicitly name alternatives or state 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?

The annotations already declare readOnlyHint: true, destructiveHint: false, and idempotentHint: true. The description adds no additional behavioral context beyond the read-only listing nature. It is consistent with annotations but provides no extra transparency about pagination, ordering, or return format.

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 concise sentence with no redundant words. It directly states the core purpose without extraneous 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?

Despite being a simple tool, the description fails to explain the critical item_id parameter and provides no usage guidance. The lack of an output schema and 0% schema coverage makes this insufficiency more pronounced. It is minimally viable but leaves clear gaps.

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

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

The input schema has 0% description coverage, so the description must clarify the parameter semantics. The description says 'from a specific brand' but does not explicitly state that item_id refers to the brand identifier. This leaves the required parameter ambiguous and forces the agent to infer its meaning from context.

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 verb 'List' and the resource 'filament products' with a specific scope 'from a specific brand'. This distinguishes it from sibling tools like list_filaments (which likely lists all filaments) and list_filament_colors.

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 provided on when to use this tool versus alternatives. There is no mention of list_filaments or other related tools, and no exclusionary criteria. The implied usage is narrow but not explicitly 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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that the tool supports pagination and search, which is useful, but it does not disclose behaviors like sorting or date filtering, which are present in the schema. 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?

The description is a single, front-loaded sentence with no wasted words. It is concise and readable, though it sacrifices detail for brevity.

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 7 parameters, no output schema, and only a one-sentence description, the tool is under-specified. The description omits information about sorting, date filtering, pagination semantics, and return structure. While the annotations help, the description alone is insufficient for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It only mentions 'pagination and search', which maps to page/page_size and search, but does not explain sort_id, sort_dir, start_date, or end_date. Parameter names are somewhat self-explanatory, but the coverage is insufficient for a 7-parameter tool.

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 verb 'list' and the resource 'custom field definitions', making the tool's purpose evident. However, it does not explicitly differentiate itself from the sibling tool 'list_custom_fields_for', which could cause confusion about 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 phrase 'with pagination and search' implies this tool is for paginated browsing of custom fields, but it gives no explicit guidance on when to use this tool versus alternatives like 'list_custom_fields_for'. No exclusions or alternative references 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the entity-scoping constraint and example, but does not disclose other behaviors such as whether includeDisabled defaults to false or what the response contains.

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 with no filler, directly states the operation and its scope. Every word adds value, and the example is useful without being verbose.

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 list tool with all-parameter enums and no output schema, the description covers the core purpose but leaves gaps: no explanation of includeDisabled, no mention of sibling alternatives, and no indication of return details. Annotations handle safety, but the description is still minimal.

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 add meaning. It explains category and subCategory with the example 'PRINT + PRINT_QUEUE', but does not explain includeDisabled, leaving one parameter semantically 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 specifies the verb 'List' and the resource 'custom field definitions', scoped by 'specific entity category and optional sub-category'. It distinguishes the tool from broader siblings like list_custom_fields, especially with the concrete example 'PRINT + PRINT_QUEUE'.

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 clearly indicates when to use this tool: to fetch custom field definitions for a specific entity category and optional sub-category. It does not explicitly name alternatives or exclusions, but the scoping is clear and the example clarifies the intended use.

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, idempotentHint, and non-destructive behavior. The description adds minimal behavioral context ('available' colors, UI use cases) beyond what annotations provide, but doesn't reveal any additional side effects or constraints.

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, concise sentence that front-loads the verb and object, then provides use-case context. Every word carries value with 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?

Given the tool's simplicity—zero parameters, no output schema, and read-only annotations—the description is sufficient. It names the resource and its intended purpose. A minor omission is the exact return format, but for a color list this is not critical.

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 schema is fully covered by definition. Description adds no parameter-specific information, but none is needed. Baseline 4 applies for zero-parameter tools.

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 operation: 'List available filament colors.' The resource is distinct from siblings like list_filaments or list_brand_filaments. However, it doesn't explicitly differentiate itself from those related list tools.

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 use-case context: 'for UI pickers or picking similar spools.' This tells the agent when to use the tool, though it doesn't mention 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?

The description goes far beyond the annotations by revealing critical behavioral details: filters are case-insensitive substring matches; amount-remaining must be reported from leftGrams/totalGrams and percentLeft, not raw total/left which are internal length in mm; density is used for gram conversion and densityIsEstimated indicates a default density assumption. These insights are not available from annotations or the schema, adding substantial transparency. No contradiction with the readOnly/idempotent 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?

Every sentence earns its place. The description is dense but well-structured: purpose first, then usage patterns, then the get_filament fallback caveat, and finally the unit/conversion warnings. No filler or repetition of schema content. It packs maximum useful guidance into a compact block appropriate for a complex 10-parameter tool.

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 10 parameters and no output schema, the description covers the essential context: how to handle large result sets (limit+sorted), the exact fields to report for remaining amount, the meaning of densityIsEstimated, and the compact default. It addresses key edge cases (specific spool lookup, unit conversion) that an agent must know to use the tool correctly. This is a complete, production-ready description.

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?

Even with 100% schema coverage, the description enriches parameter meaning. It explains the intended use of sort_by with limit, states that filters are case-insensitive substring matches, and clarifies the semantic distinction between compact modes and the raw vs computed fields (leftGrams vs raw total/left). This is exactly the type of contextual parameter insight the schema cannot convey.

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 clear, specific verb+resource statement: 'List filament spools with optional filters and sorting.' This precisely defines the tool's function and scope. It also distinguishes this tool from its sibling get_filament, which is explicitly noted as the alternative when a specific spool is named, eliminating 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?

Usage guidance is exemplary. It provides explicit 'ALWAYS pair sort_by with a limit' and gives concrete patterns for common queries (sort_by=last_used+limit=10 for most used, sort_by=created+limit=N for recent, sort_by=left for emptiest/fullest). It also clearly states when NOT to use this tool: 'If the user names a specific spool by id or 4-character short id... call get_filament instead.' This is exactly the kind of alternative selection guidance the dimension asks for.

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, idempotentHint, and destructiveHint. The description adds useful behavioral context beyond those: the default recursive search behavior, the 'full compatibility check' (not just model), and the compact data mode tuned for AI context. This enhances transparency 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?

The description is brief (three sentences) and front-loaded with the core purpose in the first sentence. It covers the most important variations without redundancy, earning its place with 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?

While there is no output schema, the description sufficiently conveys the behavior of a file-listing tool with search and compatibility options. It does not detail the return structure, but that is a minor gap given the tool's straightforward purpose and the rich parameter schema. The description is complete enough for an AI agent to select and 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?

Schema coverage is 100% and the schema descriptions are detailed for every parameter. The tool description adds a bit about pid and global_search, but these largely duplicate what the schema already states. Thus, the description provides marginal value beyond the schema, staying at baseline 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 uses a specific verb and resource ('List files and folders in the user's SimplyPrint storage'), and adds distinctive scope details: printer compatibility via pid and recursive search via global_search. This clearly differentiates it from sibling tools like get_folder, list_print_jobs, or delete_file.

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 provides clear context for when to use the tool and its variants: setting pid for printer compatibility and global_search for recursive searching. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks exclusions or alternative 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, destructiveHint=false, and idempotentHint=true, so the description need not repeat safety traits. It adds value by specifying the exact statuses returned (PENDING, DENIED, REVISION), which is useful behavioral context beyond annotations. Minor inaccuracy: 'pending approval' is slightly misleading because DENIED is not pending, but the parenthetical clarifies.

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 with no filler. It states the action, resource, and scope in minimal words, and the parenthetical adds precise status information. Every element 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 list tool with three optional pagination parameters and no output schema, the description is somewhat sparse. It lacks details on pagination behavior, return format, or how the status parameter interacts with the default statuses. The ambiguity of whether the listed statuses are defaults or allowed values further reduces completeness, though the core purpose 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?

The input schema has no descriptions (0% coverage), so the description must compensate. It partially explains the 'status' parameter by listing allowed values, but it does not clarify 'page' or 'per_page' defaults, limits, or behavior. The description also does not explicitly state that these statuses are the default filter or if they apply only when the status parameter is omitted.

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 the verb ('List') and resource ('queue items') with a specific scope ('pending approval') and explicitly lists the statuses included (PENDING, DENIED, REVISION). This distinguishes it from siblings like list_queue or get_queue_item, making the purpose 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 the tool is for viewing queue items that require attention (not yet fully approved). However, it lacks explicit guidance on when to use this tool versus alternatives like list_queue or when not to use it. The status list provides clear context but no explicit exclusions or alternative tool references.

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 readOnly/idempotent/non-destructive, so the bar is lower, but the description adds valuable behavioral context: it returns multiple printers, supports filtering, and clarifies the nuanced meaning of the 'awaiting_bed_clear' status, including how it differs from 'print_pending'. This goes well 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?

The description is a single, dense sentence that front-loads the main purpose, then efficiently covers alternatives and status meanings without redundancy. Every clause contributes to selection or invocation, making it concise despite its length.

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 16 parameters and no output schema, the description focuses on the most ambiguous aspects (status filters and misuse scenarios) and adequately covers common usage. It doesn't elaborate on return format or pagination mechanics, but those are reasonably implied/covered by the schema and the 'do not paginate' warning.

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?

While the schema covers 56% of parameters with descriptions, the description adds significant semantics for the 'status' parameter, explaining each derived status in plain language and giving direct usage examples. It also warns against pagination for farm-wide counts, indirectly guiding use of pagination 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 opens with 'List MULTIPLE printers with optional filters', clearly stating a specific verb and resource. It also distinguishes itself from sibling tools like get_printer and get_farm_overview by name, placing it precisely in the tool family.

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 instructs when not to use this tool: 'call get_printer instead' for single-printer details and 'call get_farm_overview instead' for farm-wide counts, adding 'do not list-then-filter' and 'do not paginate this'. It also provides concrete example status filters for common use cases.

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, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable behavioral context by explaining that compact mode (default) drops specific fields like gcodeAnalysis and filament breakdowns, which is not visible in annotations or schema alone.

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 action and resource, and every phrase adds value. 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 tool with 18 parameters and no output schema, the description is somewhat sparse. It covers the core purpose and compact mode but does not describe the return format or provide guidance on how to combine filters (e.g., date ranges, statuses). The schema fills most gaps, but a bit more context about output shape or common use cases would improve completeness.

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 83%, so the schema carries most parameter meaning. The description adds extra semantics for the 'compact' parameter, explaining the default and what fields it drops, which goes beyond the schema's 'Keep at default true' note. It also ties pagination/filters/sort to the overall tool behavior.

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 'List past print jobs', using a specific verb and resource that clearly distinguishes this from siblings like list_queue and list_files. It also mentions pagination, filters, and sort, giving a complete scope of the operation.

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 retrieving historical print jobs with filtering and sorting, but it does not explicitly name alternatives or state when not to use this tool. Siblings like get_print_job or list_queue exist, but no guidance is given for choosing between them.

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, idempotentHint=true, and destructiveHint=false, so the safe-read nature is covered. The description adds filter capabilities and an example, but does not disclose additional behavior such as pagination, default sort, or compact-response implications beyond what the schema descriptions already 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, front-loaded with the core action and then a dense but relevant example. There is no filler or redundant 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?

Given the 15-parameter schema with 93% coverage and strong annotations, the description provides enough orientation to select and begin using the tool. It does not explain response shape, but no output schema exists and invocation details are covered by the rich input schema.

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 93%, so the schema carries most parameter meaning. The description's older_than_days and custom_fields example is useful but largely restates the schema's own parameter descriptions without adding significant new semantics.

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 'List print queue items with optional filters', giving a clear verb, resource, and scope. It lists filtering dimensions, but does not explicitly distinguish itself from sibling tools like list_pending_queue_items or get_queue_item.

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 optional-filter framing and examples imply this is the general filtered-list tool, but there is no explicit when/when-not guidance or mention of alternatives. Given siblings like list_pending_queue_items and get_printer_queue, the usage context is only implicit.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns 'all' approval comments and that they apply to 'a queue item or user file', but does not disclose behavior when both file_id and item_id are provided, or the return format. 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?

The description is a single, concise sentence (10 words) with no redundancy. It front-loads the action and resource, making it easy 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 simple operation and strong annotations, the description is minimally viable but incomplete. It correctly states what the tool returns and the target types, but does not clarify parameter selection or behavior when both/neither parameter is supplied. An agent might struggle to know whether to pass file_id, item_id, or both.

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 hints that file_id corresponds to 'user file' and item_id to 'queue item', but it does not clarify whether these are alternatives, optional, or how to choose between them. The description adds some meaning but leaves key invocation details ambiguous.

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 retrieves all approval comments for a queue item or user file, using a specific verb ('Retrieve') and resource ('approval comments'). This distinguishes it from sibling tools like add_queue_comment, delete_queue_comment, and update_queue_comment, making the purpose 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?

No guidance is provided on when to use this tool versus alternatives, such as get_queue_item or inspect_printer_queue. There are no explicit exclusions or context cues beyond the basic function, leaving the agent to infer usage 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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the nuance of returning 'all' queue groups within the account, but does not disclose any other behavioral traits such as pagination, ordering, or filtering 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, focused sentence that directly states the tool's function without unnecessary words or repetition. It is well-structured and 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?

While the tool appears simple, the presence of an undocumented parameter is a significant gap. The description does not explain the parameter or describe the return format, making the tool contextually incomplete for an agent to use 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 input schema includes an optional parameter item_id with only type and minimum constraints, and the description provides zero explanation of its purpose. With 0% schema description coverage and no mention in the description, the agent cannot understand what item_id 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 clearly states the tool lists all queue groups in the user's account, using a specific verb and resource. It distinguishes from sibling tools like list_queue or list_pending_queue_items by focusing on queue groups rather than queue items.

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 this tool should be used when you need to list queue groups, but it does not explicitly mention alternatives or when not to use it. No exclusions or alternative recommendations 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?

Annotations indicate readOnlyHint=false, so a mutation is expected. The description adds the side effect 'resets humidity tracking', which is useful context. However, it does not disclose whether the dried_at parameter is required to overwrite the timestamp or if it defaults to the current time, nor any other behavioral nuances.

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 concise sentence that front-loads the action and outcome without any filler. Every word contributes to understanding the tool's 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?

For a simple mutation tool, the description covers the primary effect but omits parameter semantics (especially dried_at) and any prerequisites or error conditions. Given the moderate schema coverage and absence of an output schema, more contextual details would improve completeness.

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 a description for filament_id (though the comma-separated note conflicts with its integer type) and no description for dried_at. The tool description adds no parameter information, leaving the meaning and format of dried_at unclear. With only 50% schema coverage, the description should have compensated.

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 ('mark'), the resource ('filament spool'), and the outcome ('freshly dried'), including a distinctive side effect ('resets humidity tracking'). This differentiates it from related tools such as assign_filament or adjust_filament_weight.

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 used after drying a spool, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The guidance is purely implied by the phrasing.

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 read-only nature is established. The description adds the scope 'in the account' but does not explain how compatibility is determined or what the return format is. This is modest additional context beyond 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, front-loaded sentence with no redundant words. It effectively communicates the core purpose immediately.

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?

Although the tool is simple, the description lacks information about return values (no output schema) and leaves parameter meanings ambiguous. It is adequate for a basic lookup but not fully complete given the missing param and return details.

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 has 0% description coverage, so the description must compensate. However, it only mentions 'a given file' without mapping to the required 'model' parameter, and 'gcodeAnalysis' is not explained. The meaning of 'model' is ambiguous—it could refer to the file's model or something else.

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 function: finding compatible printer models for a given file. The verb 'find' and resource 'printer models' are specific, and it distinguishes itself from siblings like set_file_printers (which assigns) and list_printers (which lists all printers).

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 use case: checking compatibility before printing or assignment. It provides clear context (given a file, find compatible printers) but does not explicitly mention alternatives or when not to use this tool.

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 readOnlyHint=false and destructiveHint=false. The description adds no further behavioral context, such as whether files are removed from the source, whether overwrites occur, or any prerequisites. It only restates the action.

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 no extraneous words. While it is minimal, conciseness itself is not the issue; the sentence is appropriately short and 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?

Given that this is a mutation tool (readOnlyHint=false) with no output schema, the description should explain prerequisites or effects. It does not mention what happens on success, whether source files are deleted, or if the target folder must exist. This is incomplete for a file operation.

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%, and the description does not explain the semantics of the 'files' string or 'folder' integer. The phrase 'one or more files' hints at batch capability but leaves the format (e.g., comma-separated IDs, file names) ambiguous, failing to compensate for the lack of 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 'Move one or more files to a folder' clearly states the action (move), the resource (files), and the destination (folder). It distinguishes from sibling 'move_folder' by specifying files, though it doesn't explicitly name 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?

No guidance is provided on when to use this tool versus alternatives like move_folder, update_file, or delete_file. The description simply states the action without context 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?

The description adds no behavioral details beyond the word 'move'. Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not explain what happens to folder contents, whether overwriting occurs, or error handling. It is not contradictory, but it is uninformative.

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 concise sentence with no fluff, but it is under-specified to the point of being minimally helpful. It is not overly verbose, but the lack of additional context makes it less effective than a slightly longer, more informative 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?

Given the tool's simplicity (2 params, no output schema), the description is still inadequate. It does not mention prerequisites, side effects (e.g., recursive move), return values, or edge cases such as moving to the same location or a nonexistent target. An AI agent would need external knowledge to use this 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 input schema has two integer parameters with no descriptions, and schema description coverage is 0%. The description mentions 'another location' but does not explicitly map 'folder' to the source and 'target' to the destination, nor explain that these are IDs. It 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 clearly states the action (move) and the resource (folder), and is specific enough to distinguish from sibling tools like move_file and move_queue_item. However, 'another location' could be more explicit (e.g., 'to a different parent folder').

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 provided on when to use this tool vs alternatives, or any prerequisites (e.g., whether the target folder must exist). The description is a single sentence with no context on conditions 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 indicate a write operation (readOnlyHint=false) and non-destructive nature. The description adds the relative movement scope but provides no additional operational context such as safety considerations, prerequisites, or what happens on failure.

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 delivers the core purpose without any redundant wording. It is appropriately sized for the tool's simplicity.

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 schema and annotations handle most of the parameter and safety context, making the description sufficient for a simple action. However, it lacks any mention of limitations, prerequisites, or expected outcomes, which would be helpful for a physical movement operation.

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 fully describes all parameters (100% coverage), so the baseline is 3. However, the description's 'relative position' adds meaningful context that distance and direction are interpreted as relative movements, which is not explicitly stated in the parameter 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 clearly states the verb 'move' and the resource 'printer axis', with 'relative position' clarifying the scope. This effectively distinguishes it from sibling tools like home_printer (absolute positioning) and send_gcode (raw gcode).

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 'relative position' implies the tool is for relative moves, but it does not explicitly state when to use it over alternatives like home_printer or send_gcode. The usage context is implied rather than explicitly documented.

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 the operation is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), which aligns with the description's 'move' action. The description adds useful context by noting it can handle 'one or more' items, but it does not disclose side effects such as ordering, atomicity, or what happens to the source group, which would enhance transparency.

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

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

The description is a single, concise sentence that immediately conveys the core functionality. There is no fluff or redundant content, making it highly efficient for the agent to parse.

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 has no output schema and only minimal annotations, so the description should carry more weight. It fails to mention return behavior, error conditions, or any effects on related data (e.g., whether items are removed from the source group or if order is preserved). The description is adequate for a simple read, but for a mutating operation with batch capability, it is 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?

With schema description coverage at 0%, the description partially compensates by implying that 'jobs' refers to queue items and 'target_group_id' refers to the destination group. However, it does not specify the expected format for the 'jobs' string (e.g., comma-separated IDs, JSON array), leaving some ambiguity for the agent.

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 with a specific resource: 'Move one or more queue items to a different queue group.' It uses a distinct verb ('move') and indicates the target change (different queue group), effectively distinguishing it from sibling tools like reorder_queue_item or update_queue_item.

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 by stating the action and target ('to a different queue group'), but it does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions. There is no guidance on prerequisites or situations where this tool should be avoided.

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 provide no positive hints (readOnlyHint=false, destructiveHint=false, etc.), and the description does not add behavioral context. It does not disclose whether the pause is reversible, what happens with multiple printers, or any side effects like affecting ongoing operations.

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 concise sentence with no filler or redundancy. It is front-loaded and easy to parse, making it efficient for an agent to quickly understand the tool's 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?

For a simple one-parameter mutation tool, the description is functional but incomplete. It does not mention resumability via resume_print, behavior with multiple printers, or the response format. Sibling tools exist but are not referenced, leaving some gaps for an agent deciding whether to invoke this tool.

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

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

Schema description coverage is 100% for the sole parameter 'printer_id', so the schema carries the meaning. The tool description itself adds no parameter information. However, the schema parameter description mentions 'comma-separated' while the type is integer, a mismatch that is not clarified by the tool 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?

The description clearly states the action ('Pause') and the resource ('current print on a printer'). It is distinct from sibling tools like resume_print and cancel_print, though it does not explicitly name alternatives. The phrase 'a printer' creates slight ambiguity given the parameter accepts comma-separated IDs.

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 provided on when to use this tool versus alternatives such as cancel_print or resume_print. There are no prerequisites, exclusions, or contextual hints, leaving the agent to infer usage solely from the tool name and sibling list.

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, and the description's 'Remove' is consistent with that. However, the description adds no extra behavioral context, such as whether removal is permanent, affects a job currently printing, or how multiple jobs are processed. It meets the baseline but does not enrich beyond 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, concise sentence with no filler words. It is appropriately sized for a simple operation and front-loads the core action, making it easy 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?

This is a destructive queue operation with two undocumented optional parameters and no output schema. The description omits critical context, such as the relationship between job and jobs, whether at least one must be provided, and the consequences of removing an item. The presence of many similar sibling tools also makes the ambiguity more impactful.

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 0% description coverage, and the description provides no explanation of the 'job' and 'jobs' parameters. The names hint at a single job versus multiple jobs, but the format and semantics (e.g., how a string list is structured) are left unspecified, forcing the agent to guess.

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 'Remove an item from the print queue' clearly states the primary function with a specific verb and resource. It does not, however, differentiate this tool from similar sibling tools like delete_queue_item or empty_queue, so it loses the top score.

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 provided on when to use this tool versus alternatives such as delete_queue_item, empty_queue, or cancel_print. The description lacks any context about which scenarios call for this specific removal function or any 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 indicate readOnlyHint=false, so the mutation is known, but the description adds no behavioral details such as how positions are calculated, whether the operation is reversible, or side effects on other queue groups. No contradiction with annotations, but no additional context.

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?

Single short sentence with no redundant words. It is front-loaded and efficient, though it sacrifices detail for brevity.

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 too sparse for a tool with no output schema and no parameter descriptions. It omits return values, effects on existing queue order, and any error conditions. Incomplete for safe invocation.

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

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

Schema coverage of parameters is 0%, and the description only hints that 'to' refers to a new position. It does not define the semantics of 'to' (e.g., zero-based index, relative vs absolute) or confirm group_id is the identifier, leaving the agent to infer.

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 the action (move) and resource (queue group) with a specific outcome (new position). It distinguishes from sibling tools like reorder_queue_item and move_queue_item by specifying 'queue group'.

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 usage context is provided. The description does not mention when to use this tool versus reorder_queue_item or move_queue_item, nor any prerequisites or scenarios.

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 indicate a state-changing operation (readOnlyHint=false) but provide no safety profile. The description adds almost no behavioral context: it does not mention effects on other queue items, reversibility, or the meaning of the optional 'from' parameter. With minimal annotation support, the description carries the burden of transparency and falls short.

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 conveys the core operation without any filler. It is appropriately sized and 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?

Given the three parameters, no output schema, and the presence of similar sibling tools (move_queue_item, reorder_queue_group), the description is incomplete. It does not clarify scope within a queue, the role of 'from', or how this differs from moving an item to another queue. The lack of such context makes it difficult to select correctly among siblings.

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 that queue_item_id identifies the item and that 'to' is the 1-based position, but it completely ignores the optional 'from' parameter, leaving its purpose unexplained. This is a significant gap for a reorder operation.

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 verb 'move' and the resource 'queue item', and specifies the positional scope ('to a new 1-based position'). It distinguishes from group-level tools like reorder_queue_group by saying 'single', but it does not explicitly differentiate from the similarly named sibling move_queue_item, so it is not fully distinguished.

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 (when you need to reorder a single queue item), but it provides no explicit guidance about alternatives or exclusions. There is no mention of when not to use it or how it relates to move_queue_item, reorder_queue_group, or update_queue_item.

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 indicate a non-read-only, non-destructive mutation, and the description adds that the item transitions from denied/revision-requested to pending approval. It also discloses the file-replacement limitation, which is not visible in annotations, providing valuable behavioral context.

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 concise sentences; the first states the core action and target state, the second adds a key limitation. 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 state-transition tool, the description covers the precondition (denied/revision-requested), the outcome (pending approval), and a key limitation (no file replacement). It doesn't explain return values or the role of the comment, but given the absence of an output schema and the simplicity of the operation, it is reasonably 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%, and the description provides no explanation of queue_item_id or comment. The parameter names are somewhat self-explanatory, but the description fails to add semantic meaning beyond the schema constraints, such as the purpose of the comment field.

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 resubmits a denied or revision-requested queue item back to pending approval, using a specific verb and resource. This distinguishes it from sibling tools like approve_queue_item, deny_queue_item, and send_back_for_revision.

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 by specifying the source states (denied or revision-requested) and the target state (pending approval). The file-replacement limitation provides an explicit 'when not to use' aspect, though it doesn't name alternative tools or provide broader 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 indicate this is a mutating operation (readOnlyHint=false, destructiveHint=false). The description adds the prerequisite that the print must be paused, which is useful behavioral context. However, it does not disclose what happens if the print is not paused, whether the action is idempotent, or potential side effects. 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?

The description is a single, front-loaded sentence with no redundant wording. It efficiently states the action and target without any fluff.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is largely complete: it states the purpose and implies the core prerequisite. The annotations provide the safety profile. Minor gaps include lack of clarification about multi-printer handling or what happens if no print is paused, but these are not critical for this straightforward operation.

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 single parameter (printer_id), with the schema describing it as 'The printer IDs (comma-separated for multiple)'. The tool description adds no additional parameter semantics, so the baseline of 3 applies.

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