Server Quality Checklist

Tool Scores

• print_textB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the transparency burden. It discloses two non-obvious behaviors: text wraps to paper width and the printer parameter only overrides the active printer for this one job. However, it does not explain what happens on errors, whether the job is queued or immediate, or any permission/dependency requirements, so transparency is only partial.

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

  Conciseness4/5

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

  The description is relatively short and front-loaded with the main action, followed by parameter-specific details. All sentences earn their place, though there are minor grammar issues such as 'printer names which configured printer' that slightly reduce clarity. It avoids unnecessary fluff and is appropriately compact.

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

  Completeness3/5

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

  For a simple four-parameter tool with an output schema, the description covers the main printing behavior and two key parameters. It does not explain font_size semantics, mention how to discover valid printer names (e.g., via list_printers or scan_printers), or provide guidance around error cases. This is adequate but not fully complete for a tool with no annotations.

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

  Parameters3/5

  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 undocumented parameters. It does provide useful semantics for align (allowed values) and printer (override scope and default behavior), which add real meaning beyond the schema. However, font_size is not described at all, and text is left entirely to the schema's 'Text' title, so the compensation is incomplete.

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

  Purpose4/5

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

  The description clearly states the core action: printing a block of text on a label printer, and adds a useful detail about wrapping to paper width. This distinguishes it reasonably from sibling print_image, though it does not explicitly call out that sibling as the image alternative. Overall it is a clear, specific purpose statement.

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

  Usage Guidelines3/5

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

  The intended use is implied by the description: use this tool when you need to print text. However, there is no explicit guidance about when to choose this over print_image or any other sibling, nor any exclusion or alternative naming. It gives some operating context around the printer parameter but not tool-selection guidance.

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

• add_printerA
  3.5/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the transparency burden. It discloses the upsert side effect, the automatic first-printer activation, and that luckprinter is currently the only driver. It does not address permissions, failure modes, return values, or whether updating an existing profile resets its other settings.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the core upsert behavior comes first, the active-printer rule second, and only the necessary driver detail last. Every sentence earns its place with no redundancy.

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

  Completeness3/5

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

  For a 3-parameter configuration tool with no output schema and no annotations, the description covers the main behavior and the optional driver parameter well. It omits the address format and does not clarify the boundary with set_printer_address, so an agent lacks some situational and invocation detail.

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

  Parameters3/5

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

  The description adds strong semantics for the driver parameter, including its default value, protocol family, and rebrand examples, and it implies name is the identity key via 'if the name already exists'. The required address parameter, however, gets no format or example, so parameter coverage remains partial.

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

  Purpose4/5

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

  The description clearly states the operation ('Add (or update...)') and resource ('named printer profile'), so an agent knows what the tool does. It explicitly contrasts with select_printer for switching active printers, but it does not clarify the overlap with set_printer_address, which also modifies an existing printer's address.

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

  Usage Guidelines3/5

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

  The description provides useful context: the first configured printer becomes active automatically, and select_printer is the tool for switching afterward. However, it does not state when to use add_printer versus set_printer_address or set_printer_options, especially since the upsert behavior overlaps with those more targeted sibling tools.

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

• get_daemon_infoA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the disclosure burden. It correctly characterizes the operation as informational and includes a reachability check, but it does not explain whether the check performs network I/O, how long it may take, or how unreachable states are represented. No annotation 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.

  Conciseness5/5

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

  The description is a single sentence with no filler. It front-loads the main action and covers both key concerns in a compact, scannable way.

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

  Completeness5/5

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

  For a zero-parameter status tool with an output schema, the description sufficiently conveys purpose and expected content. It names the daemon and the two dimensions of the returned information, and does not need to describe return values because the output schema already exists.

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

  Parameters4/5

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

  The tool has zero parameters and no required arguments, so there are no parameter details for the description to clarify. The mention of daemon startup and reachability usefully previews what the result will cover, which is enough for a parameterless tool.

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

  Purpose4/5

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

  The description clearly identifies the resource (LuckJingle print daemon) and the two things the tool does: explain how to start it and report whether it is reachable. This distinguishes it from sibling printer configuration and printing tools. Minor ambiguity remains in 'explain how to start,' which suggests a human-readable narrative rather than a structured daemon-info response.

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

  Usage Guidelines2/5

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

  There is no explicit guidance about when to call this tool versus alternatives, no prerequisites, and no exclusions. The phrase 'required LuckJingle print daemon' weakly implies setup or troubleshooting context, but an agent is not directly told when this tool is the right choice.

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

• select_printerA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of explaining side effects. It discloses the core mutation and the condition under which it applies, but it does not mention whether the name must already be configured, whether the selection persists, or what happens when an unknown printer name is supplied.

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

  Conciseness5/5

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

  A single front-loaded sentence with no filler. It states the action, the affected functions, and the scope condition in a compact and readable way.

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

  Completeness3/5

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

  For a one-parameter setter, the core invocation is clear, but with no output schema and no annotations, there is no information about return values, error behavior, or persistence. An agent can call it correctly but cannot confidently predict success confirmation or failure mode.

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

  Parameters3/5

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

  Schema coverage is 0% and the description never formally maps the 'name' parameter to a configured printer identifier. However, phrases like 'which configured printer' and 'no printer is named' make it reasonably clear that the parameter is the printer name, though it could be more explicit about whether it expects a display name or exact configured label.

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

  Purpose5/5

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

  The description names a concrete verb ('Set') and a specific resource (the default configured printer used by print_text/print_image). By tying the setting to calls that omit a printer name, it clearly scopes the operation and distinguishes it from sibling printer-management tools such as add_printer, remove_printer, or set_printer_options.

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

  Usage Guidelines3/5

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

  It identifies when the setting takes effect ('when no printer is named explicitly on the call'), but it does not explicitly say when to choose this tool over alternatives or state prerequisites like 'the printer must already be configured.' The usage 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.

• remove_printerA
  3.9/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the transparency burden. It discloses a non-obvious side effect: if the active printer is removed, another configured printer becomes active. This is meaningful behavioral context for a destructive operation, though irreversibility and failure cases are not covered.

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

  Conciseness5/5

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

  The description is two short sentences with the main action front-loaded and the conditional consequence placed second. Every clause earns its place, and 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.

  Completeness4/5

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

  For a one-parameter mutation tool with no output schema, this description gives enough context to form an accurate mental model: the target resource, the operation, and the active-printer fallback. It omits edge cases like missing printer names or permanence, but those are minor for this low-complexity tool.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description never explicitly mentions the required `name` parameter. The phrase 'a configured printer' weakly implies that `name` identifies which printer to remove, but the description does not compensate for the bare schema by clarifying the parameter's meaning or expected value.

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

  Purpose5/5

  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: 'Remove a configured printer.' This cleanly distinguishes the tool from siblings like add_printer and list_printers. It further clarifies the role by stating what happens when the removed printer was the active one.

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

  Usage Guidelines3/5

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

  The intended use is implied rather than explicit: call this when you want to remove a configured printer. The description provides useful context about the active-printer fallback, but it does not explicitly compare with 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.

• scan_printersA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It explains the prerequisite daemon, the need for pairing mode, and what to look for in results (device name patterns). It doesn't detail side effects or error behavior, but for a read-only scan the provided context is valuable and goes beyond a bare operation.

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

  Conciseness4/5

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

  The description is well-structured: purpose in the first sentence, usage guidance in the second paragraph, and prerequisite in the third. It is informative without being bloated, though the device-name-pattern list is slightly long.

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

  Completeness4/5

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

  For a simple optional-parameter scan tool, the description covers the main points: what it does, how to prepare, and the runtime dependency. The missing timeout semantics is the main gap, but it is a minor one given the default value and the overall simplicity.

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

  Parameters2/5

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

  The only parameter, timeout, is entirely undocumented in both the schema and the description. The schema provides only title/type/default with zero description, and the tool description never mentions timeout, its unit, or its effect. Since schema coverage is effectively 0%, the description needed to compensate but did not.

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

  Purpose5/5

  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: 'Scan for nearby Bluetooth LE devices to find the printer's address.' This clearly distinguishes the tool as a BLE discovery/scan operation, not a management or configuration action, and it pairs well with the related get_daemon_info pointer.

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

  Usage Guidelines4/5

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

  It gives actionable context: put the printer in pairing mode before scanning, and requires the LuckJingle print daemon to be running (referencing get_daemon_info). It stops short of explicit 'when not to use' or alternatives, but the preconditions and steps are clear enough for an agent to decide when to call it.

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

• set_printer_optionsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description takes on the behavioral burden and does more than restate the operation: it explains defaults, effects of changing width/density, and the font_path's relationship to print_text. It could additionally disclose persistence, permissions, or side effects, but the behavior described is substantially transparent.

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

  Conciseness5/5

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

  The purpose is front-loaded in one short sentence, and every following clause explains one parameter without redundancy. The conditional phrasing keeps guidance tight rather than expanding into prose.

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

  Completeness4/5

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

  For a four-optional-parameter setter with no required fields and no output schema, this description covers the operation, all params, and default behavior. It does not cover error cases or explicit return behavior, but those are minor for this simple configuration tool.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate, and it does completely: each of the four parameters gets semantics, units, valid values (density 0/1/2), file-type expectations, and default behavior. This is exactly the value the schema lacks.

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

  Purpose4/5

  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 ('Tune print quality for a printer') and walks through each configurable option, making the tool's purpose clear. It does not explicitly contrast itself with sibling tools like set_printer_address or get_printer_config, so it stops short of full sibling differentiation.

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

  Usage Guidelines3/5

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

  It gives strong parameter-level usage conditions ('only change it if prints come out cropped or skewed', 'if prints look too light/dark', 'leave unset to use the printer's own default'). However, it does not say when to prefer this tool over alternatives or when not to use it, leaving tool-selection guidance implicit.

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

• print_imageA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does a solid job: it discloses that the image is resized to the printer's paper width, converted to black & white, and that dithering preserves photo/gradient edges. It also clarifies that printer applies only to the current job, leaving the active printer unchanged.

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

  Conciseness4/5

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

  The description is concise, front-loaded with the main purpose, and uses only a few sentences to cover behavior and parameter guidance. A minor typo ('printer names which configured printer') prevents a perfect score, but nothing is redundant or wasted.

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

  Completeness4/5

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

  The tool has only three parameters and no annotations; the description covers purpose, processing behavior, and the two non-obvious parameters. An output schema is present, so return-value documentation is not required here. The description is complete enough for an agent to select and invoke the tool correctly.

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

  Parameters4/5

  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 beyond the schema. It explains dither's effect and the semantics of printer, including how to fall back to the active printer. image_path is not deeply described, but the phrase 'image file (PNG/JPG/etc)' makes its purpose obvious.

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

  Purpose5/5

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

  The description begins with a clear verb and resource: 'Print an image file (PNG/JPG/etc) on the label printer.' This unambiguously identifies the tool's function and distinguishes it from sibling print_text, which handles text rather than images.

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

  Usage Guidelines4/5

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

  The description provides actionable usage guidance: use dither=True for photos/gradients and dither=False for line art/text, and explains how the printer parameter overrides the active printer. It does not explicitly name alternatives like print_text, but the purpose statement and sibling context make the intended use clear.

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

• probe_deviceA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description takes the full burden of behavior. It discloses the operation (connect, list), the expected pattern (characteristics ending in ff01/ff02/ff03), and a limitation (shared layout across incompatible protocols). It does not cover failure modes or permissions, but the core behavioral trait—that probing is not driver identification—is clearly flagged.

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

  Conciseness5/5

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

  The main purpose is the first sentence, and the second paragraph is dense but relevant usage and caveat context. No filler; every sentence earns its place.

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

  Completeness4/5

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

  The description covers purpose, usage context, expected output (GATT services/characteristics), and a caution about the tool's limitations. Missing details, such as timeout semantics and failure handling, are minor for this simple tool and there is no output schema demanding more.

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

  Parameters2/5

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

  The schema gives only field titles—'Address' and 'Timeout'—so the description must compensate. It clarifies address as a candidate BLE address from scan_printers, which helps, but it never explains what timeout controls or what format address should take; timeout is entirely unaddressed.

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

  Purpose5/5

  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: 'Connect to a BLE device and list its GATT services/characteristics.' It also clearly situates the tool in a workflow (confirming a candidate address from scan_printers before adding a printer), which differentiates it from siblings like scan_printers and add_printer.

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

  Usage Guidelines5/5

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

  It explicitly says when to use it: to confirm a candidate address found via scan_printers is a supported printer before adding it. It also provides an exclusion—the GATT layout alone does not determine the driver, so a test print is still needed—steering agents away from over-reliance. This is precise, alternative-aware guidance.

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

• get_printer_configA
  4.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden, and it does convey the read-only nature ('Return') and that it reads 'saved' configuration rather than live device state — a useful distinction from probe_device. However, it does not disclose error behavior when no active printer exists, which is a plausible runtime scenario an agent should anticipate.

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

  Conciseness5/5

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

  Two sentences with no wasted words: the primary action is front-loaded, the config contents are exemplified compactly, and the sibling routing is appended efficiently. Every clause earns its place.

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

  Completeness4/5

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

  For a zero-parameter, no-output-schema getter, the description is nearly complete: it states what is returned, scopes it to the active printer, and points to the alternative for the full list. The only gap is the edge case of no active printer being selected, which could have been stated explicitly.

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

  Parameters4/5

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

  The tool has zero parameters and 100% schema description coverage, so the schema leaves nothing undocumented. Per the baseline for 0-param tools, a 4 is appropriate; there is no parameter semantics gap for the description to fill.

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

  Purpose5/5

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

  The description uses a specific verb ('Return') with a precise resource ('the active printer's saved configuration') and cites example fields (address, driver, paper width). The qualifier 'active printer's' sharply distinguishes this from siblings like list_printers, and the final sentence explicitly names the sibling for the 'every printer' case.

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

  Usage Guidelines5/5

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

  The description gives an explicit when-to-use-alternative directive: 'Use list_printers to see every configured printer.' This states the condition under which a sibling should be chosen instead, leaving no inference burden on the agent.

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

• list_printersA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses exactly what the response contains (name, driver, address, settings, active printer) and clarifies the active printer's default behavior. It does not explicitly state that listing has no side effects, but the verb 'List' strongly implies a read-only operation.

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

  Conciseness5/5

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

  The description is a single well-structured sentence that front-loads the action and scope, then efficiently lists the output fields and adds the important clarifying detail about the active printer's role. Every word earns its place, with no redundancy.

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

  Completeness4/5

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

  For a zero-parameter list tool with no output schema and no annotations, the description provides the essential details: what is listed, what fields are returned, and how to interpret the active printer. It could additionally contrast itself with scan_printers for discovery, but that is more of an optional enhancement than a critical gap.

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

  Parameters4/5

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

  The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to add. The baseline of 4 applies because there is nothing missing for an agent to understand how to invoke the tool.

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

  Purpose5/5

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

  The description uses a specific verb ('List') with a clear resource ('every configured printer') and enumerates the return fields: name, driver, address, settings, and active printer. It also distinguishes the active printer's role in print_text/print_image, making the tool's purpose unambiguous and distinct from siblings like scan_printers or get_printer_config.

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

  Usage Guidelines4/5

  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 this tool: to see all configured printers and determine which one print_text/print_image will use by default. It does not explicitly state when not to use it or name alternatives such as scan_printers, but the usage context is concrete and actionable.

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

• set_printer_addressA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the full disclosure burden. It reveals that this mutates the currently active printer and creates a default printer if none exists—important side effects. It could go further on permissions or reversibility, but for a simple setter this is solid.

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

  Conciseness5/5

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

  The core purpose is stated in the first sentence, followed by a brief but valuable distinction from the alternative. Every sentence earns its place; no filler or repetition.

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

  Completeness5/5

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

  For a single-parameter tool with no annotations, this description covers the essential behaviors: what it does, what it affects, fallback creation, and when to choose a sibling instead. The presence of an output schema helps, but nothing needed for correct invocation is missing.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate. It clarifies that 'address' means the printer's Bluetooth address, adding semantic meaning the schema lacks. It does not specify format (e.g., MAC-style), but the core meaning is clear.

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

  Purpose5/5

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

  The description uses a specific verb ('Save') and identifies the exact resource: the Bluetooth address of the printer, for future print jobs. It also explicitly distinguishes itself from the sibling add_printer by stating when each should be used.

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

  Usage Guidelines5/5

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

  It clearly states this is a shortcut for the common single-printer case, explains what happens when no printer exists (creates 'default'), and points to add_printer for configuring multiple printers. This gives an agent unambiguous selection criteria.

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