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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the fundamental danger is known. The description reinforces with 'cannot be undone' and the explicit-intent requirement, which adds a useful confirmation nuance, but does not disclose special behaviors such as partial failures when some job IDs are invalid.

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

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

Two tight sentences with the scope front-loaded and the irreversibility warning second. No filler; every clause adds information an agent needs before calling a destructive 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?

There is no output schema, and annotations cover the safety profile, so the description need not explain returns. Still, it omits the relationship between all_jobs, printer, and job_ids (mutual exclusion? precedence?) and the role of the confirmed parameter, leaving real gaps for a destructive 4-param 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 0%, so the description carries the burden. It implicitly maps job_ids, printer, and all_jobs ('specified job IDs, or all queued jobs for one printer'), but says nothing about the required 'confirmed' flag beyond a vague 'explicit user intent', leaving one of four parameters unexplained.

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

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

States a specific verb+resource: cancelling queued Windows print jobs by ID or all queued jobs for a printer. The 'queued' scoping helps distinguish it from siblings like stop_all_printing and retry_print_job, though no sibling is named explicitly.

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

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

Implies usage via 'requires explicit user intent' and the irreversible warning, which signals caution. However, it never says when to prefer this over stop_all_printing or how it relates to retry_print_job/inspect_print_job, leaving the agent to infer.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description reinforces this with 'Does not print' plus a useful behavioral nuance: non-PDF files are 'conservatively estimated.' That estimation heuristic is genuine added context not present in the annotations.

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

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

Three short sentences, no filler, with the preview/estimate purpose front-loaded before the disclaimer. Slightly terse given the complexity, but nothing is wasted.

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 and no output schema, the description should say more about what the estimate returns (per-file counts, totals, sheet math) and how filtering options like recursive/extensions affect scope. It gives only the headline 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 only 40% across 10 parameters; copies, duplex, max_files, recursive, extensions and pages carry no description in either place. The description mentions no parameter behavior at all, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource: 'Previews selected files and estimates PDF pages and paper sheets before printing.' 'Does not print' crisply separates it from print_paths/quick_print, though it never names a sibling explicitly.

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

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

The phrase 'before printing' implies the workflow position, but there is no explicit when-to-use vs inspect_print_job or when-not guidance, and no mention of alternatives such as print_paths.

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 a closed world, so the safety profile is covered. The description reinforces this with 'Does not print,' which is genuinely useful in a print-focused toolset, but adds nothing about ordering, retention, or result shape beyond that.

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 compact sentences with the purpose front-loaded and the negative constraint last; there is essentially no filler. The 'stable history IDs' phrase is slightly cryptic but still earns its place by hinting at the return payload.

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

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

With no output schema and no annotations gap, the description does a fair job of indicating what comes back (submissions plus stable history IDs). It omits which history IDs feed which sibling tool and says nothing about the limit/counting behavior, leaving a small but real gap.

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% for the single 'limit' parameter, so the schema supplies only type/default/min/max with no meaning. The description never mentions result count, default size, or pagination, leaving the one parameter's semantics unexplained.

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

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

States a specific verb and resource ('Lists recent Printer MCP submissions and stable history IDs') and explicitly disambiguates from the print-family tools with 'Does not print.' It is clearly separable from siblings like get_print_queue or inspect_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?

The phrase 'for retry and duplicate diagnostics' gives clear context for when an agent should reach for this tool, which pairs naturally with sibling retry_print_job. It stops short of naming explicit alternatives or when-not conditions, so it is 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so 'Does not change jobs' merely restates what structured data provides. No additional behavioral context (permissions, empty-queue behavior, whether the optional parameter can be omitted) is disclosed.

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 compact sentences with zero filler, and the primary action is front-loaded ahead of the safety clarification.

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 listing tool with no output schema, the description covers the essentials. However, it leaves ambiguous behavior around the optional parameter (which printer is listed when none is supplied) and gives no sense of return shape or volume.

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

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

Schema coverage is 0% and the single 'printer' parameter is optional, so the description carries the burden. It usefully clarifies that the value may be a printer name or an alias, but says nothing about accepted syntax or what happens when the 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?

States a specific verb and resource ('Lists current print jobs') with scope ('for one printer or alias'), which separates it from the historical sibling get_print_history by the word 'current'. It stops short of naming an alternative explicitly, so a 5 is not warranted.

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

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

Usage is only implied: the word 'current' suggests checking live queue state, and 'Does not change jobs' reassures it is a safe read. There is no statement of when to prefer this over inspect_print_job, list_printers, or get_print_history, and no prerequisites 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value with 'Does not print,' preempting the confusion that a print-settings tool might trigger output, and by enumerating the returned categories; it stops short of describing format or defaults.

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

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

Two short sentences, zero filler, with the content enumeration front-loaded and the scope-limiting caveat placed at the end where it reads as a qualifier. 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?

With no output schema, the description usefully enumerates what is returned (aliases, profiles, duplicate window, safety threshold), which is the right compensation. It does not indicate structure or default values, but for a parameterless read tool this is close to complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The schema is an empty object, consistent with the parameterless signature.

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 ('Lists') and enumerates exactly what it retrieves: printer aliases, path aliases, profiles, duplicate window, and safety threshold. This clearly separates it from the set_*/remove_* siblings and from queue/history tools, though it does not name a specific alternative tool.

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

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

There is no explicit statement of when to call this versus siblings like list_printers or get_print_queue. The only usage signal is the negative 'Does not print,' which implies it is safe to consult settings before acting, but that guidance is left to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Does not print' is largely redundant with the structured safety profile. The description adds the useful domain framing of what selection semantics are applied, but says nothing about return shape, truncation at max_files, or whether results are capped.

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

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

Two tight sentences: the capability first, the crucial disambiguating constraint second. Every clause earns its place with no filler.

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

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

For a read-only preview tool with no output schema, annotations carry the safety burden and the description covers the selection surface. The main residual gap is the return shape (file list? match count? would-be page count?) given the print-job naming, but that is a minor omission.

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

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

Schema coverage is only 57%, but the description names six of the seven selection mechanisms (paths, aliases, recursion, extension, glob, exclusion, date filters), effectively compensating for undocumented schema entries. Only max_files goes unmentioned in both places, though its 500/1000 bounds are self-explanatory.

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

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

States a specific verb (previews) and enumerates what is being selected (files by path/alias/recursion/extension/glob/exclusion/date). The closing 'Does not print' cleanly separates it from print_paths and quick_print. It does not, however, explicitly differentiate itself from estimate_print_job, which is the closest conceptual sibling.

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 negative constraint 'Does not print' implicitly tells the agent when this tool is wrong (i.e., when actual printing is wanted), but no sibling is named and no positive trigger condition is given. The agent must infer that this is the dry-run/preview counterpart to the print 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, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds useful behavioral context by specifying what is enumerated (installed printers, aliases, default printer) and reinforcing non-printing, though it omits details like permissions, pagination, or output 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?

Two short sentences with zero waste, front-loading the primary action and scope before the clarifying 'Does not print' clause. Every sentence earns its place.

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

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

For a zero-parameter, read-only listing tool with rich annotations and no output schema, the description sufficiently explains what will be returned (printers, aliases, default) and what will not happen (printing). No essential information is missing for correct invocation.

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

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

The tool has zero parameters, which sets the baseline at 4. The description does not need to explain parameter semantics, and no gaps exist to compensate for.

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

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

States a specific verb (Lists) and resource (installed Windows printers, aliases, default printer), clearly distinguishing it from print-action siblings like print_paths and quick_print. The phrase 'Does not print' further sharpens the boundary.

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

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

Provides clear context that this is a listing tool and explicitly not a printing tool, which implies when to use it. However, it does not name alternatives (e.g., get_print_queue) or state exclusions or prerequisites, leaving usage to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description reinforces this with 'Does not print' and adds that path checks may be local or UNC, but says nothing about runtime, whether UNC probes require credentials or network access, or how results are reported. With annotations carrying the safety burden, this is adequate but not rich.

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

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

Two short sentences with zero filler, and the scope enumeration plus the non-printing constraint are front-loaded. Every clause carries information an agent needs.

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 no-output-schema read-only diagnostic, the description covers what is checked and the non-destructive nature well. It stops short of describing the shape of the health report or how partial failures on UNC paths surface, which would fully close the gap.

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 single 'paths' parameter, so the description must compensate. It does add meaning by noting the paths are optional and may be local or UNC, which aligns with required=0. It still does not explain expected path format, array behavior, or what happens when a path is unreachable, so compensation is partial.

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

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

States a specific verb (checks) and enumerates the exact resources inspected: Windows printing, default printer, PDF engine, Office apps, local storage, and optional local/UNC paths. The closing 'Does not print' separates it decisively from action-oriented siblings like print_paths and quick_print, so an agent can route correctly without opening a schema.

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

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

The description implies diagnostic usage and rules out printing, which is useful routing context. However, it never states when to run this versus alternatives such as get_print_settings or list_printers, nor any prerequisites or when-not-to-use conditions. Usage is inferred rather than specified.

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, readOnlyHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds real context beyond that: the confirmation gate, duplicate protection, and a large-job safety threshold. It stops short of explaining what happens when the threshold is exceeded or how force interacts with it, which the schema partially fills.

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

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

Two tight sentences with the capability summary front-loaded and the confirmation requirement placed prominently. Nothing is padded, though the terseness is arguably a symptom of under-documentation rather than disciplined editing.

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 17-parameter destructive tool with no output schema and only 35% schema description coverage, the description is far too thin. It never explains filter combination behavior, what the safety threshold does when tripped, what the duplicate check compares, or what the caller receives back on a partial failure.

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 35% across 17 parameters, so the schema does not carry the load. The description names categories that map loosely to parameters (aliases, profiles, filters, safety threshold), but many parameters such as pages, copies, duplex, orientation, monochrome, and recursive get no clarification anywhere. It partially compensates but leaves a large 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 states a specific verb and resource ('Prints selected files') and enumerates the capability surface (aliases, profiles, filters, duplicate protection, safety threshold). It is clearly distinguishable from administrative siblings like set_printer_alias or list_printers, though it never names the close sibling quick_print or estimate_print_job, which an agent must pick between.

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 one real prerequisite: explicit user intent plus confirmed=true. That is useful when-to-use signal, but there is no guidance on choosing this over quick_print or estimating first with estimate_print_job, and no when-not conditions. Usage is implied rather than routed.

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, so the safety profile is carried by structured data. The description reinforces the gate by stating confirmed=true is required, but it never discloses what is actually destroyed or consumed (paper, printer state, job submission) or whether the action is reversible. The framing as "parses" also mildly understates the destructive behavior the annotations declare, though it does not directly 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?

A single tight sentence with no filler, and the precondition is placed after the capability rather than buried. Slightly back-loaded for a destructive tool, but there is no wasted text.

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, no-output-schema tool with zero parameter documentation, the description is thin. It says nothing about what a successful call produces, which printer/profile it targets by default, what "preview" and "force" actually change, or how failures surface — all things an agent needs before invoking an irreversible 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 coverage is 0%, so the description must carry the load. It partially does: it identifies "command" as the argument text from /print and enumerates the kinds of tokens it may contain (flags, aliases, profiles, filters, preview, force), and it states the required value of "confirmed". It still omits the concrete syntax or examples of the command string, so compensation is incomplete.

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

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

The verb is "parses" and the resource is "the argument text from /print," which is mechanically specific but leaves the user-visible effect ambiguous — it never states that a print job is actually submitted. It also fails to distinguish itself from close siblings like print_paths, estimate_print_job, or inspect_print_job, so an agent must guess which print entry point applies.

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 one real precondition — "Requires explicit slash-command intent and confirmed=true" — which tells the agent when the tool is legitimate. However, it names no alternatives and no when-not-to-use conditions, so the routing decision among the 17 sibling print tools is left entirely to inference.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description usefully bounds the blast radius by stating it affects only a saved alias/profile and not files, printers or queued jobs, which is the key added context for a removal tool. It does not state reversibility, required permissions, or behavior on a missing name, so it goes only slightly beyond the annotations.

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

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

Two short sentences, zero filler, with the destructive action and its scope limitation front-loaded before any 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 simple two-parameter removal tool with no output schema, the description covers what is removed and what is unaffected, which is most of what an agent needs. It stops short of covering failure modes (unknown name), permission requirements, and whether the removal can be undone, so it is not fully complete.

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

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

Schema description coverage is 0%, so the description carries the burden; it partially compensates by naming the three deletable kinds that map to the 'kind' enum and noting only one item is removed per call. It says nothing about the 'name' parameter, such as whether it must match an existing alias exactly or whether lookup is case-sensitive.

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 ('Removes one saved printer alias, path alias, or print profile') and enumerates exactly the three kinds the sibling set_* tools create. An agent can distinguish it from set_printer_alias, set_path_alias and set_print_profile without opening a schema.

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

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

Usage is implied by the verb and the enumerated kinds, and the second sentence clarifies scope ('Does not affect files, printers, or queued jobs'). However, there is no explicit when-to-use framing, no mention of the counterpart set_* tools, and no prerequisite or error guidance (e.g., what happens if the named alias does not exist).

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, so the mutation risk is covered; the description adds useful context the annotations cannot, namely that it replays the original files and options and that a confirmed=true user-intent gate is mandatory. It does not say whether the reprint can be cancelled or what a failed replay leaves behind.

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

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

Two tight sentences; the action is front-loaded and the safety condition follows immediately with no filler.

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

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

With no output schema and annotations already covering the safety profile, the description supplies action, source of data, and the confirmation gate. It leaves minor gaps about failure behavior and whether the reprint is interruptible, but nothing essential to correct invocation is missing.

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

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

Schema coverage is 0%, so the description must carry parameter meaning, and it does: history_id is identified as a 'prior Printer MCP history ID' and confirmed is tied to 'explicit user intent ... confirmed=true'. UUID format and the const:true constraint remain only in the schema, but both parameters are semantically explained.

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

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

States a specific verb and resource ('Prints the original files and options') and scopes the source to a prior history ID, which separates it from quick_print and print_paths. It stops short of explicitly contrasting with the closest sibling, inspect_print_job, which also takes a history ID.

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

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

Gives a clear precondition: 'Requires explicit user intent and confirmed=true.' This tells the agent when the call is legitimate, though it never names alternatives (e.g., re-running via quick_print, or inspecting first with inspect_print_job).

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

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

Annotations already declare this is a non-destructive, non-open-world write, so the bar is lower. The description adds real context beyond them: it discloses that the operation is an upsert ('creates or replaces'), that existing aliases will be overwritten, and that the target path is validated for existence before the write.

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

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

A single tight sentence with the verb and resource front-loaded and no filler. Every clause (creates/replaces, @alias, local or UNC path, existence verification) carries information.

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

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

For a two-parameter tool with no output schema and annotations covering the safety profile, the description is nearly sufficient: it covers mutation semantics, target validation, and path scope. Minor gaps remain on failure modes (e.g. what happens if verification fails) and alias collision handling.

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

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

Schema coverage is 0%, so the description carries the burden and does partially compensate: it names the alias as 'short @alias' and characterizes the path as a 'local or UNC file/folder path'. It still does not describe the alias character restrictions or error behavior for an invalid/duplicate alias, so the compensation is partial.

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

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

States a specific verb pair (creates or replaces) and a specific resource (a short @alias for a file/folder path), so the agent knows exactly what this tool produces. It separates itself from set_printer_alias by resource type (path vs printer), though that differentiation is implicit rather than called out.

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 'after verifying that it exists' gives an implied precondition for the path argument, which is useful context. However there is no explicit when-to-use guidance, no when-not to use it, and no alternative named (e.g. set_printer_alias for printers).

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context by disclosing upsert semantics ('Creates or replaces'), which the annotations do not convey, but it says nothing about what happens to an existing alias beyond replacement, permission requirements, 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?

A single sentence, front-loaded with the operation and resource, with no filler. Nothing here needs trimming or reordering.

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

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

For a simple two-parameter tool with annotations present and no output schema, the description covers the essentials minimally. It is adequate but leaves the 0%-documented parameters and the replace-overwrite behavior under-specified.

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

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

Schema description coverage is 0%, so the description carries the entire burden for two parameters and mostly fails. 'Short alias' hints at the alias naming intent but omits the enforced pattern (^[a-zA-Z0-9_-]+$) and gives no guidance on how the printer argument is identified (name vs. queue).

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

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

The description names a specific verb pair ('Creates or replaces') and a precise resource ('a short alias for an installed Windows printer'), so an agent can distinguish it from set_path_alias, which targets paths rather than printers. It stops just short of explicitly contrasting the two siblings, so a 4 rather than 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?

There is no statement of when to use this tool versus set_path_alias or set_print_profile, and no prerequisites or exclusions. The phrase 'for an installed Windows printer' only faintly implies a precondition that the printer must already exist.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-open-world operation. The description adds genuinely useful context with 'creates or replaces', signaling upsert-by-name overwrite behavior, but does not address permissions, whether an existing profile of the same name is silently clobbered, or any 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?

One front-loaded sentence, no filler, the core action ('creates or replaces') leads and the covered fields follow. Nothing needs trimming or reordering.

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

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

For a 7-parameter mutation tool with no output schema, the description covers the mutating fields and upsert semantics, and annotations carry the safety profile. It still leaves gaps on the required, pattern-constrained 'name' parameter and the 'pages' string syntax, which an agent would need to nail for a correct call.

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

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

Schema description coverage is 0%, so the description carries the burden and largely succeeds: it maps six of the seven parameters (copies, printer/alias, color/monochrome, duplex, orientation, PDF pages). It omits the required 'name' parameter and the enum values for duplex/orientation, which the agent must still discover from the schema.

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

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

States a specific verb pair ('creates or replaces') and a precise resource ('reusable print profile'), then enumerates the settings it covers. It is distinguishable from siblings like set_printer_alias or quick_print, though it never names those alternatives explicitly.

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

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

The word 'reusable' implies the intended context (saving settings for repeated use rather than one-off printing via quick_print or print_paths), but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage must be inferred from the 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 this is a non-read-only, non-destructive, closed-world mutation, so the safety profile is covered. The description adds which two behaviors are configured, which is genuine context, but it omits whether omitted parameters are left unchanged, what defaults are, and whether changes apply to active jobs.

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

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

A single front-loaded sentence with no filler; both configurable settings are named immediately and nothing redundant is included.

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

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

For a two-parameter mutation with annotations covering the safety profile, the entry is serviceable but leaves real gaps: no defaults, no statement that omitted fields are preserved, and no unit for the threshold, which is ambiguous given the 1-1000 bound. An agent can call it, but may not be able to predict the effect 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 description coverage is 0%, so the description must carry the burden, and it does map both parameters to real meanings (safety_threshold = large-job file threshold, duplicate_window_minutes = duplicate-print detection window). However it never clarifies the unit or basis of the threshold (files, pages, size), and the schema's min/max bounds and 'and/or' optionality are the only other semantics available.

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

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

The description names a specific verb (Updates) plus the two exact settings touched, large-job file threshold and duplicate-print detection window, which distinguishes it from the alias, profile, and print-execution siblings. It stops short of explicitly contrasting with the nearest neighbors, but an agent can identify the tool's domain without opening the schema.

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

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

There is no statement of when this tool should be used, no prerequisites, and no reference to any alternative sibling such as get_print_settings or set_print_profile. The 'and/or' phrasing hints that either parameter may be supplied, but that is the only usage signal.

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, so the safety profile is covered. The description adds the crucial irreversibility statement ('cannot be undone') and the explicit-request gate, which are meaningful beyond the annotations, though it says nothing about the state of partially printed jobs or error handling.

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

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

Two tight sentences with zero waste; the scope is front-loaded and the danger/precondition follows 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?

For a one-parameter, no-output-schema destructive tool, the description supplies enough: scope, irreversibility, and activation gating. Only the required 'confirmed' argument's mechanics are left entirely to the 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 0% and the single required parameter 'confirmed' is never mentioned in the description. The const:true constraint makes the intent partly self-evident in the schema, and the 'explicit user request' language loosely maps to it, but the description does not tell the agent that it must pass confirmed=true.

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

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

States a specific verb (Cancels), resource (every job in every installed print queue), and exhaustive scope. The 'every ... every' wording implicitly separates it from the targeted sibling cancel_print_jobs, so an agent can route without opening the schema.

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

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

Gives a concrete precondition: it should only fire on an explicit '/print stop' or equivalent user request. That is clear when-to-use guidance, though it never names cancel_print_jobs as the scoped alternative for partial cancellation.

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