Server Quality Checklist

Tool Scores

• optimize_mirrorsA
  3.6/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates safe read-only behavior, and the description adds useful context beyond that: it explains what each action does (e.g., 'auto_test' after listing, 'health' provides recommendations) and gives concrete examples. This clarifies behavior without contradicting annotations.

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

  Conciseness4/5

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

  The description is compact, containing a brief summary and action list in a single sentence, with examples that make it actionable. It is front-loaded with a label ('[MIRRORS]') and could be slightly better structured by separating the action list from examples, but it remains efficient.

  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?

  While the core actions are covered, the description omits the 'suggest' action entirely, despite it being a valid enum value. It also does not address return values or edge cases, and given the tool's multi-action nature, this gap reduces completeness beyond what the schema provides.

  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 100%, so parameters are fully described in the schema. The description adds marginal value by showing usage examples (e.g., auto_test=True) but does not provide deeper meaning or relationships beyond what the schema already documents.

  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 identifies the tool as 'Smart repository management' and lists specific actions ('status', 'test', 'health'), making the purpose fairly clear and distinguishing it from sibling tools that handle packages or updates. However, it omits the 'suggest' action from the enum, leaving an incomplete picture of the tool's full capability.

  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?

  Action descriptions provide implied usage (e.g., 'test' for speed testing, 'health' for full checks), and examples show how to invoke actions. But there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites, leaving the selection criteria somewhat implicit.

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

• manage_patternsA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's action descriptions (list all patterns, details about a specific pattern) add basic behavioral context without contradicting the annotation. It does not discuss error handling, output format, or edge cases, but the annotation reduces the burden.

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

  Conciseness4/5

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

  The description is concise and includes concrete examples, but the leading '[ORGANIZATION]' placeholder is unnecessary noise. Overall, it is efficient and front-loaded with the core purpose.

  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 read-only tool with two parameters, the description covers the available actions and parameter usage. The lack of an output schema is mitigated by phrases like 'all patterns' and 'details about a specific pattern'. It does not address invalid pattern names, but overall it is adequately complete.

  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 input schema covers 100% of parameters with descriptions, so the description adds little beyond examples. The example values ('base') illustrate usage but do not add semantic meaning beyond what the schema already provides.

  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 clearly identifies the tool as 'Unified zypper pattern management' and enumerates two specific actions (list_patterns, pattern_info), making its purpose distinct from sibling tools focused on package management, updates, and system checks. The examples further reinforce what the tool does.

  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 example invocations and indicates that this is for pattern management, giving clear context. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusion criteria. Usage is implied rather than explicitly guided.

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

• analyze_rpm_macrosA
  3.8/5.0
  Behavior4/5

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

  With readOnlyHint=true, the description adds useful context beyond the annotation: it lists specific return values (CFLAGS, MAKEFLAGS, compression settings, build configuration) and the platform restriction (SUSE Linux). It does not describe return formatting or failure modes, but for a read-only analysis tool this is adequate.

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

  Conciseness3/5

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

  The description is short but contains redundancy: the return values are listed twice with slightly different wording ('build configuration' vs 'build directory configuration'). The second sentence mostly repeats the first, making it less concise than it could be.

  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?

  Given the tool is simple (no parameters, no output schema, readOnlyHint annotation), the description covers the essential aspects: what it does, what it returns, and the platform limitation. The slight ambiguity about 'build configuration' vs 'build directory configuration' prevents a perfect score.

  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 0 parameters, so the rubric baseline is 4. The description does not need to explain parameter meanings that do not exist, and it does not attempt to invent any. This is appropriate for a parameterless 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 explicitly states the tool's function: 'Parse and analyze rpm macros.' It identifies a specific resource (rpm macros) and a specific action (parse and analyze). This clearly distinguishes it from sibling tools like analyze_zypper_conf or analyze_storage, which target different resources.

  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?

  The description lacks any guidance on when to use this tool versus alternatives. It only notes 'Only works on SUSE Linux,' which is a platform constraint, not a usage condition. No prerequisites, scenarios, or recommended context are provided.

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

• get_system_infoA
  3.8/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description adds valuable context by listing the exact data returned (SUSE variant, kernel, architecture, memory) and noting it works on any system. This goes beyond the annotation, though it could have mentioned output format or whether elevated permissions are needed.

  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 two sentences and front-loads the purpose with the 'MONITORING' tag. There is slight redundancy between the two sentences (both mention kernel and architecture), but overall it is concise and to the point, without unnecessary filler.

  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 no-parameter tool without an output schema, the description is fairly complete: it explains what information is returned and notes platform compatibility. It lacks details like the exact return format or suggested use cases, but the given information is sufficient for basic invocation and interpretation.

  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 no parameters, so schema coverage is trivially 100%. The baseline for zero parameters is 4, and the description appropriately focuses on the output rather than parameter details, which are irrelevant here. It adds no unnecessary parameter descriptions.

  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 tool's action ('Get comprehensive system information') and specifies the resource (system information) with a list of fields (kernel version, architecture, hostname, uptime, memory). It is specific enough to distinguish from most siblings, though it doesn't explicitly name any sibling alternatives.

  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 includes a 'MONITORING' tag and says 'Works on any system', which implies a general monitoring use case. However, it does not explicitly explain when to use this tool versus a sibling like 'diagnose_system' or 'analyze_storage', nor does it provide any exclusions or prerequisites.

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

• manage_orphansA
  3.9/5.0
  Behavior1/5

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

  The description explicitly says 'remove orphaned packages' and requires sudo for removal, indicating destructive operations. However, annotations set destructiveHint=false, which directly contradicts the described behavior. This is an annotation contradiction.

  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 well-organized, front-loading the purpose, then providing constraints and examples. Every sentence adds value and the examples are illustrative without being verbose.

  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?

  Covers actions, platform, privileges, and usage examples, and explains the output for 'list' (disk usage). However, it does not describe the return value for 'remove' (other than dry-run preview), leaving some ambiguity.

  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 coverage is 100%, but the description adds meaningful examples (list shows disk usage, dry_run preview, exclude list) that clarify parameter behavior and default values beyond the schema.

  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 clearly states it is a 'unified tool for managing orphaned packages' with two specific actions ('list' and 'remove'), distinguishing it from sibling tools like 'remove_packages' by focusing on orphans. The verb and resource are explicit.

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

  Usage Guidelines4/5

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

  Provides clear platform and privilege context ('Only works on SUSE Linux', 'Requires sudo access for removal') and concrete examples for each action. However, it does not explicitly name alternative tools 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.

• run_system_health_checkA
  3.9/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true indicates safety, and the description adds a key behavioral constraint: "Only works on SUSE Linux." This is important platform-specific behavior not captured by annotations. The description also lists what the tool checks, giving the agent a sense of the scope. No contradictions with annotations.

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

  Conciseness3/5

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

  The description is only two sentences but suffers from redundancy. The first sentence already lists "disk space, failed services, updates, orphan packages, and more," and the second sentence repeats a very similar list with "database freshness" and "critical news" added. This redundancy could be tightened without losing information, though it is not overly verbose.

  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?

  The tool has a simple interface (no params, no output schema), so the description must explain what it does and what it returns. It does a good job of explaining the checks performed, but it does not describe the output format or whether the result is a summary, verbose report, or exit code. The agent may not know what to expect from the invocation despite knowing the inputs.

  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?

  With zero parameters and full schema coverage (vacuously), the baseline is 4. The description appropriately focuses on what the tool does rather than parameter details. No parameter explanation is needed, and the description does not introduce confusion about parameters.

  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 clearly states the tool's purpose: "Run a comprehensive system health check." It specifies the resource (system health) and the action (run a check), and distinguishes itself from sibling tools by emphasizing its comprehensive nature, integrating multiple diagnostics into a single overview. The list of included checks further clarifies scope.

  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 implies usage for a complete health overview, but it does not explicitly provide when-to-use/exclusion criteria or mention alternatives. The "comprehensive" framing suggests it is the all-in-one tool, but there is no direct guidance such as "use this for a general overview, or use sibling tools for specific checks." The SUSE Linux constraint is a prerequisite, not a usage guideline.

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

• verify_package_integrityA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful context about platform restrictions ('Only works on SUSE Linux') and the detection capabilities (modified, missing, corrupted files). However, it does not disclose deeper behavioral details such as required privileges, output format, or whether checksum databases are auto-updated, leaving the description at a baseline level given the annotation coverage.

  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 concise and front-loaded, starting with a clear purpose statement, followed by platform and usage notes. Every sentence provides valuable information: the action, the detection targets, the OS limitation, and the recommended trigger. No redundant or filler content.

  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 tool with one parameter and no output schema, the description covers the essential context: it defines the function, specifies the platform, gives a typical use case, and implies the expected result (checksum verification). It is sufficient for an agent to select and invoke the tool correctly, though it could optionally mention the exact form of the output (e.g., affected files list) for completeness.

  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 input schema has 100% coverage with a clear description for package_name ('Name of the package to verify'). The tool description does not add extra semantics beyond what the schema provides, and the mention of 'linux' as a specific package is just an example, not a parameter default. Since schema coverage is high, the baseline score of 3 is appropriate.

  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 clearly states the tool's purpose: 'Verify the integrity of installed package files. Detects modified, missing, or corrupted files.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_official_package_info or analyze_storage. The platform limitation to SUSE Linux and the example of verifying 'linux' further clarify the tool's scope.

  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 explicit when-to-use guidance: 'After system crash or disk errors, verify 'linux' package files match expected checksums.' This gives clear context for appropriate use, though it does not explicitly mention alternatives or when-not-to-use scenarios, so it stops short of a 5.

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

• query_file_ownershipA
  4.1/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, so the safe-read nature is already known. The description adds value by specifying the SUSE Linux requirement and showing example outputs, but it does not disclose error handling, return format details, or behavior for empty/missing results. The description does not contradict annotations.

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

  Conciseness4/5

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

  The description is well-structured, front-loading the purpose and then elaborating three modes with examples. It is a bit long but every sentence contributes practical information. The examples are valuable, though they could be condensed slightly.

  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?

  Given the tool's moderate complexity (3 params, 3 modes, optional filter) and lack of an output schema, the description does a solid job covering usage scenarios with examples and platform constraints. It doesn't address edge cases like invalid queries or exact regex syntax, and the filter_pattern example may mislead, but the core functionality is well explained.

  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 input schema already provides 100% coverage for all parameters, so the baseline is 3. The description adds meaning by giving concrete examples of parameter combinations (e.g., mode='file_to_package', query='/usr/bin/python') and illustrating expected outputs, which clarifies how the mode and query interact. The filter_pattern example uses a glob-like pattern while the schema says regex, which is a minor inconsistency, but overall the description provides added clarity.

  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 clearly states the tool's purpose as 'querying file-package ownership relationships' and explicitly lists three distinct modes with concrete examples, making it distinct from sibling tools like query_package_history or get_official_package_info. The platform constraint 'Only works on SUSE Linux' further sharpens its scope.

  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 each of the three modes, with examples and expected results, and notes the SUSE Linux limitation. However, it doesn't explicitly mention alternative tools or state when not to use this tool, so it falls short of a 5.

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

• diagnose_systemA
  4.2/5.0
  Behavior4/5

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

  The readOnlyHint annotation already marks this as a safe read operation. Beyond that, the description adds meaningful behavioral context: it lists the two diagnostic actions and explicitly states the systemd-only limitation. This helps the agent understand what the tool checks (failed services) and retrieves (boot logs), and under what conditions it applies. No contradictions with annotations.

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

  Conciseness5/5

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

  The description is a single, compact sentence with a clear [MONITORING] tag upfront. It packs the core purpose, the available actions, and the systemd constraint into a minimal number of words without redundancy. Every part earns its place, making it easy to parse and act upon.

  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 tool with low complexity (one required enum param, one optional param, no output schema), the description is sufficient to understand what it does and under what constraints. The absence of an output schema means return values are not explicitly described, but the actions are simple enough that an agent can infer the likely diagnostic output. Slight deductions for not mentioning any error conditions or prerequisites beyond systemd.

  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 schema already covers both parameters (action, lines) with 100% coverage, so the baseline is 3. However, the description adds semantic meaning to the action enum values by explaining what each action does ('check for failed systemd services' and 'retrieve recent boot logs'), which is not present in the schema's generic description. This elevates the score above baseline.

  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 clearly states the tool's purpose: 'Unified system diagnostics for systemd-based systems' and enumerates the two specific actions (failed_services and boot_logs) with brief explanations. This distinguishes it as a diagnostic tool focused on systemd systems, setting it apart from siblings like get_system_info or run_system_health_check.

  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 gives a clear environment constraint ('Works on systemd-based systems only') which implies when the tool is appropriate, but it does not explicitly mention alternatives or when not to use it. For example, it doesn't say 'for non-systemd systems, use X' or compare with run_system_health_check. Thus, 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.

• get_official_package_infoA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, and the description aligns by stating 'Get information'. It adds valuable behavioral detail by disclosing the dual-mode implementation: 'Uses local zypper if available, otherwise queries the OBS API.' It also hints at return fields (version, dependencies, install size, repository location). No contradiction with annotations.

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

  Conciseness5/5

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

  The description is compact and well-structured: a clear purpose clause, method explanation, usage preference, and a concrete example. Every sentence adds value, and it is front-loaded with the core purpose.

  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?

  With no output schema, the description provides example return fields ('version, dependencies, install size, and repository location'), which is sufficient for an info tool. It also covers method and selection criteria. Minor gap: no mention of error behavior if package is not found or if both local zypper and OBS API fail, but overall it is complete enough for selection and invocation.

  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 100% with a clear description for package_name ('Exact package name'). The description provides an example ('python3') but does not add extra semantics beyond what the schema already states. This matches the baseline score for high schema coverage.

  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 starts with a specific verb and resource: 'Get information about an official SUSE repository package.' It clearly differentiates from siblings like search_obs by emphasizing 'official' vs 'OBS community packages'. The example query further clarifies what the tool does.

  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 gives clear guidance to prefer official packages over OBS community packages ('Always prefer official packages over OBS community packages'), which effectively tells the agent when to use this tool over alternatives. However, it does not explicitly mention when not to use it or name alternative tools for community packages.

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

• install_obs_packageA
  4.2/5.0
  Behavior4/5

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

  The description enriches the destructiveHint annotation by detailing the multi-step workflow: fetching OBS metadata, analyzing spec file, blocking on critical issues, and adding repo then installing via zypper. It also discloses sudo requirement and SUSE-only limitation. This adds meaningful behavioral context beyond the single annotation.

  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 with the core purpose, followed by a numbered workflow that earns its place. There is no redundant wording or unnecessary detail, making it highly scannable.

  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 prerequisites (SUSE, sudo), the security-check workflow, and the installation mechanism. It does not mention return values or that the added OBS repo persists, but given the simple schema and destructiveHint annotation, it is reasonably complete for an install operation.

  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 schema already describes package_name as 'Name of package to install from OBS' with 100% coverage. The description does not add additional parameter-level details, so it meets the baseline of 3 for schema-covered parameters.

  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 explicitly states the tool 'Install a package from OBS with security checks', using a specific verb and resource. The workflow further clarifies the security-checking aspect, distinguishing it from sibling tools like search_obs or audit_obs_security which are not install tools.

  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: 'Only works on SUSE Linux' and 'Requires sudo access', plus the workflow indicates it is for installing with security checks. However, it does not explicitly name alternatives or state when not to use, so it lacks the highest level of guidance.

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

• analyze_zypper_confA
  4.3/5.0
  Behavior4/5

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

  The readOnlyHint annotation already establishes that the operation is safe, and the description goes beyond by disclosing platform-specific behavior, conditional output based on focus, and the presence of warnings and optimization recommendations for certain focus values. This provides substantial context without contradicting the annotation.

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

  Conciseness4/5

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

  The description is moderately sized but each sentence contributes value: purpose, output summary, platform constraint, and concrete examples. The examples are slightly redundant with the schema's enum definitions, but they add behavioral nuance, so there is minimal waste.

  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 single-parameter tool with read-only behavior, the description covers the essential aspects: what is parsed, what is returned, supported focus values, and output variations. It does not specify the exact return format, but the absence of an output schema and the tool's simplicity make this acceptable.

  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 schema fully documents the focus parameter with enum values and descriptions, but the description adds practical meaning—e.g., 'ignored_packages' returns warnings for critical ones, and 'parallel_downloads' includes optimization recommendations. This enriches the parameter semantics beyond the schema's basic definitions.

  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 clearly states the tool's function: parsing and analyzing zypper.conf, with a specific list of output categories. It distinguishes itself from sibling tools by targeting this particular configuration file, and the platform constraint ('Only works on SUSE Linux') further clarifies its scope.

  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 gives clear context for when to use the tool—when zypper.conf settings need analysis—and includes a platform limitation. However, it does not explicitly mention alternatives or conditions under which a different tool would be preferable, so it lacks exclusionary guidance.

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

• query_package_historyA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true. The description adds that it reads from zypp logs and restricts to SUSE Linux, plus indicates the nature of results (recent transactions, failures, sync history). This goes beyond the annotation to clarify the data source and query semantics.

  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 front-loaded with the primary purpose and then details the four query types with concise examples. While longer than ideal, every sentence contributes useful information, and the format is easy to scan.

  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?

  Given the tool's complexity (four query types, conditional parameter), the description covers the main use cases and output intent. It lacks explicit return format details, but the absence of an output schema and the read-only nature make this acceptable.

  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 100%, but the description adds meaning by explaining each enum value with examples and clarifying that package_name is required for query_type='package'. This enriches the schema's bare descriptions.

  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 clearly states the tool queries package history from zypp logs, listing four specific query types with concrete examples. This distinguishes it from sibling tools like check_updates_dry_run and verify_package_integrity by focusing on historical log data.

  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 explicit usage context for each query type via examples (e.g., 'package' for when a package was installed, 'failures' for errors). It also notes the platform restriction ('Only works on SUSE Linux'). It doesn't explicitly contrast with alternatives, but the examples 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.

• search_obsA
  4.3/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already covers the tool's safety profile, and the description adds no behavioral traits beyond confirming it searches and returns info. No contradictions, but also no extra context about pagination, rate limits, or required permissions, so baseline 3 is appropriate.

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

  Conciseness5/5

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

  The description is three sentences with no fluff. The '[DISCOVERY]' tag adds context, and each sentence serves a purpose: what it does, a caution about official repos, and a concrete use case. Perfectly front-loaded and efficient.

  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?

  Given the tool's moderate complexity and the absence of an output schema, the description adequately covers the return values (project, repository, description). It also gives the intended use case, making the description complete 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.

  Parameters3/5

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

  The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description does not add any parameter-specific meaning beyond confirming the query searches for packages, and it does not mention limit or sort_by.

  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 states 'Search the Open Build Service (OBS) for packages' with a specific verb and resource, and clarifies it returns package info. It explicitly differentiates from get_official_package_info by noting official repos should be checked first, making the tool's role distinct.

  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 provides clear when-to-use guidance: 'Always check official repos first using get_official_package_info' and states the use case as searching community-maintained packages. This explicitly names the alternative tool and the condition for using this one.

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

• search_opensuse_wikiA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description aligns with this by saying 'Search' and 'Returns'. It adds useful context about the return format (titles, snippets, URLs) and provides an example query, which goes beyond the annotation. No additional behavioral traits like rate limits or prerequisites are mentioned, but for a simple read-only search tool this is adequate.

  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 concise, with three sentences that are front-loaded with the [DISCOVERY] tag and a clear statement of purpose. Every sentence adds value: what it does, what it returns, how to use it, and an example. No fluff.

  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?

  Given the low complexity of the tool, good input schema, and readOnly annotation, the description adequately covers the return value, usage preference, and an example. There is no output schema, but the description explicitly states what the return contains, so the agent is fully informed.

  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 input schema already provides 100% coverage for both parameters (query and limit), with descriptions for each. The tool description adds an example query ('zypper') and clarifies the utility, but this is marginal enrichment rather than essential semantic information. Baseline of 3 is appropriate.

  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 clearly states the verb 'Search' and the resource 'openSUSE Wiki', and specifies that it returns a list of matching pages with titles, snippets, and URLs. The scope is distinct from sibling tools like search_obs, which focuses on the Open Build Service, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  Provides explicit guidance to prefer Wiki results over general web knowledge for SUSE-specific issues, which helps with selection. However, it does not explicitly mention when not to use the tool or name alternative tools, so it falls short of the highest bar.

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

• analyze_storageA
  4.4/5.0
  Behavior4/5

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

  The description adds platform-specific behavior beyond the readOnlyHint annotation, explaining that cache_stats is SUSE-only. It also clarifies that disk_usage checks 'critical paths,' giving context without contradicting the read-only annotation.

  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?

  Three concise sentences front-load the core purpose, list actions with inline details, and end with platform constraints. No wasted words; 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?

  For a simple tool with one enum parameter and no output schema, the description covers purpose, actions, and platform compatibility. It doesn't mention return format, but the tool's scope is small enough that this is acceptable.

  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 description enriches the enum parameter by explaining each value: disk_usage 'check disk space for critical paths' and cache_stats 'analyze zypp package cache.' This goes beyond the schema's generic 'Analysis type to perform' description.

  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 clearly states 'Unified storage analysis tool' and lists two specific actions (disk_usage, cache_stats) with brief explanations. This specific verb+resource scope distinguishes it from sibling package management and system diagnosis tools.

  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 explicit platform usage guidance: 'Works on any system for disk_usage, SUSE only for cache_stats.' This tells the agent when each action is applicable, though it doesn't mention alternative tools or exclusions.

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

• audit_obs_securityA
  4.4/5.0
  Behavior4/5

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

  With readOnlyHint=true, the read-only safety profile is already covered by annotations. The description adds value by elaborating the two execution modes (spec scan vs. full fetch-and-audit) and providing example calls, which clarifies behavior beyond the annotation. It could mention network access or result format, but this is not a significant gap given the annotation.

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

  Conciseness5/5

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

  The description is three sentences, each serving a distinct purpose: stating the tool's function, breaking down actions, and providing a usage directive. The [SECURITY] prefix and clear examples make it highly scannable with zero fluff.

  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 moderate complexity with two actions and four parameters. The description covers the actions, examples, and usage timing comprehensively. It omits return-value details, which could be useful for an audit, but annotations and schema cover safety and parameters, making it sufficient for correct selection and invocation.

  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 100%, so the baseline is 3. The description enriches parameter understanding by associating spec_content with spec_analysis and package_name with full_audit, and by offering concrete example values. This clarifies the conditional usage of parameters, earning an above-baseline score.

  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 clearly states 'Comprehensive security audit for OBS packages' with specific verb 'audit' and resource 'OBS packages'. It lists two distinct actions (spec_analysis, full_audit) with examples, making its scope unambiguous and differentiating it from sibling tools like search_obs or install_obs_package.

  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 provides an explicit directive: 'Always audit OBS packages before installing', establishing a clear when-to-use context tied to the install workflow. However, it does not explicitly name alternative tools or mention when-not-to-use cases, so it falls short of a full 5.

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

• check_database_freshnessA
  4.4/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates a safe read operation, so the description adds value by disclosing the 24-hour staleness threshold and the SUSE-only limitation. It also clarifies that the tool only warns (does not auto-refresh), which is a useful behavioral trait beyond the annotation.

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

  Conciseness5/5

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

  The description is three sentences, includes a useful [MAINTENANCE] tag at the start, and contains no filler. Every sentence contributes to understanding the tool's purpose, constraints, and usage context.

  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 tool with no parameters and no output schema, the description adequately covers what it does, when to use it, and its OS limitation. It doesn't mention the exact output format (e.g., timestamp or status message), but this is not critical for selecting/invoking the tool, especially given the simplicity.

  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?

  With zero parameters in the input schema, the baseline is 4. The description does not need to explain parameters since none exist, and it correctly refers to 'package databases' as the target without implying any configurable options.

  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 clearly states the tool checks when package databases were last synchronized and warns if they are stale (> 24 hours). This specific verb+resource combination distinguishes it from siblings like check_updates_dry_run and verify_package_integrity, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides an explicit 'When to use' section ('Check if zypper cache is stale and needs zypper refresh'), which gives clear context. It also notes the SUSE Linux restriction. However, it does not explicitly mention when not to use it or name alternative tools, so it loses a point for lacking exclusions.

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

• fetch_newsA
  4.4/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description explains the three action modes and the critical platform limitation (SUSE only for since_update). It adds meaningful behavioral context for a read-only tool, though it doesn't detail return format or error behavior.

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

  Conciseness5/5

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

  Two concise sentences with an action list and platform note. No redundancy, front-loaded with purpose, and every clause adds value.

  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 a simple parameter set and clear annotations. The description covers the main behavior and constraints, but lacks explicit return-value details or examples. Given the schema is thorough and the tool is not highly complex, this is reasonably complete.

  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 covers all parameters, giving baseline 3. The description enriches the 'action' parameter by explaining what each action means and adds a key constraint (platform dependency for since_update) that is not in the schema. This extra context justifies a 4.

  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 clearly states the tool fetches news from openSUSE and enumerates three specific actions (latest, critical, since_update). It distinguishes itself from sibling tools, none of which are news-related, and provides a specific verb + resource.

  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 implies this is the go-to tool for openSUSE news and provides a clear platform constraint (SUSE only for since_update). It does not explicitly name alternatives or exclusions, but the context is clear given the sibling list and the 'Unified news fetching' phrasing.

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

• check_updates_dry_runA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, but the description adds valuable context: platform restriction (SUSE Linux), emphasis on no changes being applied, and note that it shows pending updates with sizes. This goes beyond the structured annotations.

  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 sentences with a lifecycle prefix, immediately states the purpose, then adds platform and usage notes. No wasted words and well front-loaded.

  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 read-only tool, the description covers what it does, platform constraints, use case, and output expectation (pending updates and sizes). It is fully adequate given the simplicity and available annotations.

  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 an empty schema, so the baseline of 4 applies. There are no parameter semantics to describe, and the description doesn't need to discuss them.

  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 clearly states the tool checks for available system updates without applying them, specifies it only works on SUSE Linux, and mentions it shows pending updates. This distinguishes it from sibling tools like install_obs_package or remove_packages.

  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 an explicit 'When to use' scenario: before running system updates, to check what packages will be upgraded and their sizes. However, it doesn't name alternative tools or describe when not to use it, so it's clear but not exhaustive.

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

• manage_install_reasonA
  4.5/5.0
  Behavior4/5

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

  Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses behavioral effects: mark_explicit prevents orphan removal, mark_dependency enables auto-removal with orphans, and list returns user-installed packages. It also notes the SUSE Linux constraint. This adds meaningful context about consequences and environment, though it doesn't mention authentication or error handling, which are not critical here.

  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 well-structured: it opens with a clear overview, lists the three actions, states the platform restriction, and then provides illustrative examples. No sentence is wasted; each part contributes to understanding how to use the tool.

  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?

  The tool has a small parameter set and no output schema, yet the description covers all essential aspects: actions, required parameters, behavioral outcomes, and platform compatibility. It is sufficiently complete 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 coverage is 100%, so baseline is 3. The description adds value by explaining the effect of each action with concrete examples (e.g., mark_explicit with 'python-pip' keeps the package), and clarifies that package_name is needed for mark actions. This enriches the schema descriptions with behavioral meaning.

  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 clearly states the tool's purpose: 'Unified tool for managing package install reasons.' It lists three specific actions (list, mark_explicit, mark_dependency) with concise definitions, and includes examples that further clarify functionality. This distinguishes it from sibling tools like remove_packages or manage_orphans by focusing on install reason state rather than removal.

  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 each action via examples (e.g., 'action='list' → returns all user-installed packages') and states the platform restriction ('Only works on SUSE Linux'). However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.

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

• remove_packagesA
  4.7/5.0
  Behavior5/5

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

  Annotations only provide destructiveHint: true, but the description adds significant context: the danger of force removal ('dangerous!'), the platform requirement (SUSE Linux), and the sudo access requirement. It also clarifies the behavior of each mode (with dependencies, forced removal, batch removal) beyond what the annotation conveys.

  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 enough, with a clear lead sentence and examples that illustrate behavior. It is slightly long but every clause adds useful information (platform, sudo, examples). It is well-structured, though initial front-loading could be slightly tighter.

  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 destructive tool with three parameters and no output schema, the description covers all essential aspects: accepted input types (string or list), the two boolean flags, platform constraint, permission requirement, and dangerous force mode. It also provides multiple usage examples, making it complete for an agent to invoke correctly.

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

  Parameters5/5

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

  Although the schema already provides parameter descriptions (100% coverage), the description adds practical semantics through examples: 'packages='firefox', remove_dependencies=true → removes Firefox with its dependencies' and the caution on force. This clarifies how parameters interact in real scenarios, adding value beyond the schema.

  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 clearly states the tool's function: 'removing packages (single or multiple)' with a specific verb and resource. It also distinguishes itself as the 'unified tool' for package removal, which differentiates it from sibling tools focused on updates, querying, or installation.

  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 usage: 'Only works on SUSE Linux' and 'Requires sudo access'. It also gives concrete examples illustrating when to use the different parameter combinations. However, it does not explicitly mention when not to use this tool in favor of siblings, leaving that implicit.

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