Server Quality Checklist

Tool Scores

• get_process_infoA
  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 of disclosing behavior. It explicitly states 'Does not modify system state,' which is a key read-only trait. However, it does not mention potential failure modes (e.g., process not found), permission requirements, or whether the operation is instantaneous or expensive. For a simple getter, this is minimal but adequate; additional error or side-effect disclosure would improve it.

  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 tightly written sentences. The first sentence front-loads the core purpose and the exact fields returned; the second sentence gives usage guidance and a behavioral note. Every word earns its place, with no filler or repetition. This is a model of concise structuring.

  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 that an output schema exists and defines the return structure, the description does not need to enumerate return fields. It covers the purpose, input, usage context, and non-destructive nature. It does not cover error cases or provide details on how to handle invalid pids, but for a simple informational tool this is near-complete. The absence of explicit alternatives slightly reduces completeness, but the reference to list_processes anchors the workflow well.

  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% because the description never explicitly names 'pid' or describes its format. However, the phrase 'specific process' and the single required parameter make it obvious that pid is the process identifier. The description indirectly compensates by establishing the context, but it does not add explicit detail like units or allowed range. Given there is only one obvious parameter, this is acceptable but not exceptional. A 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 input (a specific process) and the output (PID, parent PID, name, status, user, CPU%, memory%, command line, working directory). It explicitly says 'specific process' and references list_processes, distinguishing it from sibling tools like get_cpu_usage that report system-wide metrics. This is a specific verb-resource pairing with no ambiguity.

  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 guidance: 'Use this when investigating a specific process identified by list_processes or other tools.' This tells the agent when to invoke it and ties it to a workflow. It does not explicitly state when not to use it, but the context of 'specific process' vs. the sibling set makes the exclusion implicit. The note 'Does not modify system state' adds a relevant constraint. Slightly more explicit comparison to alternatives would earn a 5.

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

• get_service_logsA
  4.1/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 of behavioral disclosure. It explicitly states 'Does not modify system state,' which is a valuable safety trait. It does not detail output format or error handling, but for a simple read operation 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 two crisp sentences that front-load the purpose and usage context without wasted words. Every sentence 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?

  For a tool with two simple parameters and an existing output schema, the description is largely complete: it covers purpose, when to use it, and the non-modifying nature. The missing parameter explanation is the only shortfall, but it is a minor one given the tool's 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?

  Schema description coverage is 0%, so the description must compensate. It clarifies that 'service' refers to a systemd service, but it does not explain the 'lines' parameter or its default of 50. This is a notable gap given the lack of schema 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 uses a specific verb ('Returns') and a precise resource ('journal log lines for a systemd service'). It clearly distinguishes the tool from siblings like get_service_status (status, not logs) and restart_service (mutation).

  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 explicit context for when to use the tool ('when investigating why a service failed, crashed, or is misbehaving'). However, it does not name alternative tools or state when not to use it, leaving some inference to the agent.

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

• git_logA
  4.1/5.0
  Behavior4/5

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

  Annotations are absent, so the description carries the full burden. It clearly discloses read-only behavior ('Does not modify system state') and constraints (max entries limit, allowed roots). This adds important context beyond the schema and compensates for the lack of 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 concise, with the core purpose and constraints in the first paragraph and usage guidance in the second. It is appropriately front-loaded and contains no unnecessary 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?

  Given an output schema exists, the description covers essential aspects: purpose, constraints, and when to use. It does not mention errors or edge cases, but for a simple read-only log tool this is sufficient.

  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. It explains the max_entries limit (max 100) and the repo path constraint (must be within allowed roots), but does not fully elaborate on the repo parameter's expected format or purpose. It adds some value but leaves gaps.

  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 a specific verb and resource ('Returns the most recent Git log entries'), details the content (commit hash, author, date, message), and distinguishes it from sibling git tools by focusing on history investigation. It is clear and 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 explicitly states when to use the tool ('investigating recent commits, looking for when a change was made, or identifying who made modifications'). It does not explicitly name alternatives or when not to use it, but the guidance is sufficient for an agent to select it correctly.

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

• git_statusA
  4.1/5.0
  Behavior4/5

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

  Annotations are absent, so the description carries the full burden. It discloses both the safety profile ('Does not modify system state') and a key behavioral constraint ('repo path must be within allowed roots ~/Projects, ~/Documents'). These are the two most important behavioral facts for invoking a read-only status tool correctly.

  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 sentences with zero waste: the first fronts the core purpose and return contents, the second states the path constraint, and the third gives usage context plus the safety note. 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?

  With an output schema present, return values need no description. The write-up covers the operation, the path constraint critical for correct invocation, when to use it, and its non-mutating nature. The only gap is error behavior for invalid or out-of-scope paths, which is minor for a simple single-parameter read-only tool.

  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%, but the description compensates by explaining the repo parameter is a path that must fall within the allowed roots (~/Projects, ~/Documents). This adds meaningful semantics beyond the bare 'repo: string' schema entry, though it omits details like whether relative paths are accepted.

  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 states a specific verb and resource ('Returns the Git status of a repository') and enumerates exactly what is included: branch, ahead/behind counts, modified, untracked, and deleted files. This clearly separates it implicitly from siblings like git_diff (changed content) and git_log (history), though no sibling is named explicitly.

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

  Usage Guidelines4/5

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

  It gives explicit when-to-use guidance: 'Use this when investigating uncommitted changes, branch status, or repository state.' However, it never names alternatives or states when not to use this tool, so an agent must infer that git_diff or git_log are the choices for diff or history needs.

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

• run_testsA
  4.2/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 of behavioral disclosure. It reveals key traits: the command is fixed (never LLM-supplied), the operation is read-only ('Does not modify system state'), and the repo path must be within allowed roots. These are important for an agent to use the tool safely and correctly, though it does not cover return format details (handled by output schema).

  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 paragraphs, front-loaded with the primary purpose. Every sentence adds distinct information: operation, security constraint, return contents, usage context, and side-effect guarantee. 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?

  Given the simplicity of the tool (single parameter) and the presence of an output schema, the description covers all critical aspects: what it does, when to use it, constraints, and non-modification guarantee. Minor gaps like timeout or concurrency behavior are not present, but for a read-only test runner these are not essential.

  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 for the only parameter 'repo' has no description (0% coverage). The description adds the constraint 'repo path must be within allowed roots', which provides some semantic value beyond the schema. However, it does not clarify path format or what constitutes a valid repository, leaving the agent to infer from the noun 'repository' used in the text.

  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 a specific verb ('Runs') and resource ('pytest in a repository'), and specifies the output (pass/fail status, summary, list of failing tests). It is immediately distinguishable from all sibling tools, which are system monitoring and file/git operations.

  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 explicitly says 'Use this when investigating test failures or verifying that changes haven't broken tests.' This provides clear context for when to invoke the tool. It does not mention alternatives or exclusions, but given the sibling set, no direct alternative exists, so the guidance is adequate.

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

• search_filesA
  4.2/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. It discloses the 100-entry cap, the path restriction ('within allowed roots'), and explicitly states 'Does not modify system state' for read-only behavior. These are useful behavioral traits beyond the schema. It does not cover error handling or symlink behavior, but the output schema covers return format.

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

  Conciseness5/5

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

  The description is four sentences, each adding distinct value: main purpose, constraints, usage context, and non-mutation. It is front-loaded with the primary function and wastes no words. Structure is clear and efficient.

  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 simplicity (2 params, output schema present), the description covers the essential aspects: what it does, constraints (cap, path whitelist), when to use, and that it's read-only. Missing details like error conditions or exact return structure are minor because the output schema exists. It is complete enough for an agent to invoke correctly.

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

  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. It clarifies that 'pattern' is a glob pattern and implies 'path' is the directory root (via 'within a directory tree' and 'Path must be within allowed roots'). This adds meaning beyond parameter names, but it does not specify pattern syntax or path type in detail. The baseline of 3 is appropriate given the compensation is adequate though not exhaustive.

  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 'Searches' and resource 'files matching a glob pattern within a directory tree'. It distinguishes from siblings like list_directory (which lists without pattern matching) and read_file (which opens a specific file) by emphasizing glob pattern search. The purpose is specific and 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 explicit guidance: 'Use this when looking for specific files by name or extension within a project.' This gives a clear context for use. However, it does not mention when not to use it or name alternative tools, so it lacks exclusions or direct comparisons to siblings.

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

• get_listening_portsA
  4.3/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 burden of behavioral disclosure. It states 'Does not modify system state,' which is a key read-only property. It does not mention potential performance implications, permissions, or return format nuances, but the core safety trait is covered. Given no annotations, this is reasonable but not exhaustive.

  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 short sentences, each serving a purpose: what it returns, when to use it, and that it is non-destructive. It is front-loaded with the core function and contains no filler.

  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 tool with an output schema present, the description covers everything needed to call it correctly: the action, the scope (TCP/UDP ports with process info), and the safety profile. No further details are necessary.

  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, so the baseline is 4. The description adds no parameter details (none needed) and the schema coverage is 100% (empty schema), so no compensation is required. The description's mention of output fields (PID, process name, bind address) aligns with the output schema context.

  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 ('Returns') and the resource ('all currently listening TCP and UDP ports') along with the associated process information. It is distinct from sibling tools that cover system info, CPU, memory, processes, etc., so an agent can immediately identify its purpose.

  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 explicitly says 'Use this when investigating port conflicts, checking if a service is listening, or diagnosing network issues,' giving clear usage context. It does not list alternative tools or exclusions, but the context is strong enough for correct selection among siblings.

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

• get_service_statusA
  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. It clearly states 'Does not modify system state,' which is the key behavioral trait for a read-only introspection tool. It does not mention potential permission requirements or failure modes, but for a status check, this is adequate and non-contradictory.

  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 zero fluff. The core function and returned fields are front-loaded, followed by usage guidance and a safety note. Every sentence earns its place.

  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 one-parameter read-only tool with an output schema, the description covers purpose, use case, and behavioral constraints. No missing information would prevent an agent from calling it correctly. Return values are already defined by the output schema.

  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% for the single 'service' parameter. The description says 'systemd status of a service,' which implies the parameter is a service identifier, but it does not specify it as a name, give examples, or note constraints (e.g., valid unit names). It adds minimal meaning beyond the schema, though the parameter is straightforward.

  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 returns systemd status with specific fields: active state, sub-state, enabled, and activation timestamp. This is a specific verb and resource, distinct from siblings like get_service_logs (logs) and restart_service (modification). No ambiguity remains about 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 explicitly says 'Use this when investigating whether a specific service is running, failed, or misconfigured.' It also notes 'Does not modify system state,' which differentiates it from restart_service. It does not explicitly name sibling alternatives, but the guidance is clear and actionable.

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

• restart_serviceA
  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 full burden. It openly discloses 'STATE-CHANGING operation' and 'REQUIRES human approval before execution', which are critical behavioral traits. It does not mention failure modes or side effects, but given the simple nature of a restart, 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 three sentences with no filler. The core action is front-loaded, the mutating nature and approval requirement are clearly highlighted, and the usage guidance is succinct.

  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 low complexity (one parameter) and the presence of an output schema, the description covers all essential aspects: purpose, when to use, and critical behavioral disclosure. Minor gaps like error handling or prereq checks are not critical for this simple operation.

  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%, so the description must compensate. However, it offers no details about the 'service' parameter beyond the tool's purpose—no expected format (e.g., unit name vs. full path), no examples, no constraints. This leaves the agent to infer even basic parameter semantics.

  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 a specific verb ('restarts') and resource ('a systemd service'), and explicitly notes it is the only mutating tool in the set. This distinguishes it clearly from the read-only sibling tools.

  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 provides clear usage context: 'Use this only when a service needs to be restarted as a remediation step and the user has been informed.' It also explicitly names that it is the only mutating tool, implicitly excluding all read-only alternatives.

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

• get_cpu_usageA
  4.4/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 full burden. It discloses that the tool is non-destructive ('Does not modify system state') and describes its read-only nature. It could add more on return format, but the output schema exists to fill that gap.

  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 sentences, all information-dense. The key resource and scope are front-loaded, followed by usage context and a behavioral note. No 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 zero-parameter read-only tool with an output schema, this is nearly complete. It explains what data is returned, when to use it, and that it's non-destructive. It could mention the output schema structure, but that's redundant since the output schema 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 schema coverage is 100%, so the schema already trivially covers everything. The description adds useful information about what the output contains (overall/per-core percentages, load averages), which enriches understanding beyond the empty 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 what the tool does: returns current CPU utilization as overall and per-core percentages plus load averages. It is specific and distinguishable from sibling tools like get_memory_usage or get_disk_usage.

  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 ('when investigating high CPU usage, system slowness, or load-related issues') and notes it does not modify system state. It doesn't explicitly mention alternatives, but the context is clear enough.

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

• read_fileA
  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 burden. It discloses key behavioral facts: size cap (100KB), path root restrictions, and that it's a non-mutating operation. It does not mention error handling or binary file behavior, but the output schema likely covers return semantics. This is solid disclosure for a read tool.

  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 no superfluous information. The key operation and limitations are front-loaded, and every clause adds value. Perfectly sized for the tool's simplicity.

  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 complexity (single parameter) and the presence of an output schema, the description covers operational constraints, usage guidance, and safety. It doesn't address edge cases like binary files or symlink resolution, but these are minor for a basic read tool. Overall, sufficient for reliable 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 0%, but the description adds meaningful constraint on the 'path' parameter (must be within allowed roots) and clarifies the file type (text). This compensates for the lack of schema docs and helps the agent construct a valid path.

  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 a specific verb ('Reads'), a resource ('text contents of a file'), and explicit constraints (cap at 100KB, path within allowed roots). This clearly distinguishes it from sibling tools like list_directory or get_file_metadata, which serve different purposes.

  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 explicit use cases ('investigating file contents, checking configuration files, or reading source code') and notes that it does not modify system state. While it doesn't explicitly name alternatives or exclusion conditions, the usage context is clear enough for an agent to decide when to invoke it.

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

• get_disk_usageA
  4.5/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 full burden. It explicitly discloses a key behavioral trait: 'Does not modify system state' (a read-only guarantee). It also clarifies scope ('all mounted partitions'). For a simple zero-parameter monitoring tool, this is sufficient and helpful.

  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 zero filler. The first sentence front-loads exactly what the tool returns; the second gives usage guidance and a safety note. Every word earns its place.

  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-argument, read-only system monitoring tool with an output schema, the description covers purpose, output specificity, usage context, and safety. Nothing an agent needs to decide whether or how to call it is missing. The output schema likely details the return structure, so the description does not need to repeat it.

  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, so the baseline is 4. There is no parameter information to add, and the description naturally does not attempt to explain nonexistent parameters. The output schema is not shown but its existence covers return fields.

  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 a specific verb ('Returns') and resource ('disk usage for all mounted partitions') and spells out the output fields (total, used, free in GB, used percentage per mount point). It is clearly distinct from sibling monitoring tools like get_cpu_usage or get_memory_usage.

  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 context: 'when investigating low disk space, full partitions, or storage issues.' It does not name alternatives or when-not-to-use, but the tool's specificity makes that unnecessary. The added note 'Does not modify system state' further guides safe usage.

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

• get_file_metadataA
  4.5/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. It discloses that the tool does not modify system state and that the path must be within allowed roots, which are important behavioral facts. It doesn't cover error responses or symlink behavior, but for a read-only metadata 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?

  Two sentences with zero redundancy. The first states the purpose and outputs; the second gives usage guidance and a safety note. Every word earns its place, and the key information is 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 simple one-parameter, read-only tool with an output schema, the description fully covers purpose, usage, constraints, and behavior. The output schema handles return values, so nothing essential 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 provides meaning for the 'path' parameter by stating it 'must be within allowed roots', implying a validated path. This is additional context beyond the schema's mere type definition and is sufficient for a single required string parameter.

  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 'Returns' with a specific resource 'metadata about a file or directory' and lists the exact fields (path, size, type, modification time, permissions). This distinguishes it from sibling tools like list_directory (which lists entries) and read_file (which reads contents).

  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 explicit when-to-use guidance ('investigating file properties, checking permissions, or assessing file sizes') and implicitly signals non-modification ('Does not modify system state'). However, it does not name alternatives or exclude specific cases, but the context is clear enough for an agent to choose this over content-reading tools.

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

• get_memory_usageA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description must carry behavioral disclosure. It explicitly states 'Does not modify system state,' which is a valuable safety guarantee. It does not discuss error conditions or prerequisites, but for a simple read-only 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?

  Two concise sentences with no redundant words. The first sentence conveys the core purpose, the second gives usage context and a behavioral note. Each sentence earns its place and the key function is 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?

  Given the simplicity of the tool (no parameters, output schema present), the description covers all essential aspects: what it returns, when to use it, and its non-destructive nature. The output schema presumably handles return-value details, so nothing critical 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?

  The tool has zero parameters, so there is nothing to document. Per the baseline rule for no parameters, this scores 4, and the description correctly omits any parameter details.

  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 a specific verb ('Returns') and a clear resource ('system memory and swap utilization') with output format ('percentages and GB'). This clearly distinguishes it from siblings like get_cpu_usage and get_disk_usage by its specific focus on memory and swap.

  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 explicitly tells the agent when to use it: 'Use this when investigating high memory usage, swapping, or general system slowdown.' This gives clear context but does not mention alternatives or when-not to use, so it misses the full 5-level guidance on exclusions.

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

• get_system_infoA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description adequately carries the behavioral disclosure burden by explicitly stating 'Does not modify system state.' This covers the key safety concern for a read-only info tool. It could mention that no privileges are needed, but the non-modification statement is strong enough for this scope.

  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 well-structured: the first sentence enumerates the returned fields, the second provides usage guidance and a safety note. Every sentence adds value with no redundancy or filler.

  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 tool with an output schema, the description fully captures what an agent needs to know: what it returns, when to use it, and that it is non-mutating. No critical information is missing for correct invocation.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description appropriately does not attempt to explain parameter semantics since there are none. It correctly focuses on the return content instead.

  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 a specific verb ('Returns') and a specific resource ('basic system information') with an explicit list of included fields. It clearly distinguishes itself from sibling tools like get_cpu_usage and get_memory_usage by focusing on system-level identity and health rather than resource-specific metrics.

  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 usage scenarios ('investigating general system identity, checking OS version, or assessing basic system health') that guide an agent on when to call it. While it doesn't explicitly name alternatives or when not to use it, the context is sufficient given the tool's simplicity and the sibling set.

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

• list_directoryA
  4.5/5.0
  Behavior4/5

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

  With no annotations present, the description carries the full burden. It discloses that it does not modify system state and restricts the path to allowed roots, which are essential behavioral constraints. It does not detail error handling or response format, but for a simple listing tool, the provided disclosures are 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?

  Three sentences with no redundancy. The primary purpose is front-loaded in the first sentence, followed by constraints and usage guidance. Every sentence contributes value without excess.

  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 an output schema (even though not shown), the description explains what is returned (names, types, sizes) and the key constraint (allowed roots). It is complete for an agent to correctly select and invoke the tool. No critical missing information.

  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 compensate. It does by explaining the allowed path values ('within allowed roots (~/Projects, ~/Documents)'), which is meaningful beyond the bare schema property 'path'. It doesn't specify absolute vs relative paths, but the root restriction is a key semantic.

  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 'Lists' the resource 'contents of a directory' and specifies the output includes file/directory names, types, and sizes. It is distinct from sibling tools like get_file_metadata, search_files, and read_file, even without naming them explicitly.

  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 explicitly says 'Use this when investigating directory contents, checking project structure, or looking for specific files,' giving clear context for when to invoke it. It also notes 'Does not modify system state,' implying it's safe for read-only exploration. However, it does not explicitly mention when not to use it or point to alternatives for other scenarios.

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

• list_processesA
  4.5/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. It explicitly states 'Does not modify system state,' which is a key behavioral disclosure. It also mentions the sorting by CPU and the limit with max 200. However, it does not disclose any potential performance implications or permission requirements, which might be relevant for a system inspection tool.

  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. The first sentence conveys the main functionality, the second provides usage context, and the third states a safety property. No wasted words; every sentence adds value.

  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 that there is an output schema (context signal), the description need not explain return values. It covers purpose, usage, behavior, and the single parameter. The tool is simple (one optional parameter, no nested objects), so the description is complete for an agent to call it appropriately.

  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 explains that the tool is 'Limited to `limit` entries (max 200),' giving functional meaning to the limit parameter beyond the schema's type and default. The default of 50 is left to the schema, which is acceptable since the schema provides it.

  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 and resource: 'Returns a list of running processes sorted by CPU usage, showing PID, name, CPU%, memory%, and status.' It further clarifies the purpose with 'when investigating which processes are consuming the most resources,' which distinguishes it from sibling tools like get_cpu_usage or get_process_info.

  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 explicitly says 'Use this when investigating which processes are consuming the most resources,' providing a clear context for use. It does not explicitly name alternatives or state when not to use it, but the sibling list and the tool's purpose make the appropriate usage clear.

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

• git_diffA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states output is capped to prevent context flooding with a truncated flag, the repo path must be within allowed roots, and the tool does not modify system state. These are concrete behavioral traits that an agent needs to know, making this highly 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 description is two short paragraphs with no filler. The primary function is front-loaded in the first sentence, with key behavioral notes (truncation, allowed roots) following immediately. The second paragraph provides usage guidance without redundancy. Every sentence earns its place.

  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 an output schema, so return value details are covered there. The description covers the critical aspects: what it returns, truncation behavior, path restrictions, read-only nature, and usage context. It is complete for an agent to decide when and how to call it 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?

  The schema provides zero descriptions for the two parameters (repo and cached), so the description must add meaning. It implicitly explains the 'cached' parameter through the phrase 'comparing working tree to index, or reviewing staged changes,' which maps directly to cached=true. While repo is self-explanatory, the description could be more explicit about parameter semantics, but it does give enough context to guide correct invocation.

  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 returns a Git diff for a repository, listing changed files and diff text. It distinguishes this tool from siblings like git_status and git_log by focusing on the diff operation and explicitly mentioning the 'cached' parameter's role in comparing working tree to index.

  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 specifies when to use the tool ('investigating what code changes were made, comparing working tree to index, or reviewing staged changes') but does not explicitly mention alternatives or when not to use it. While these use cases clearly separate it from other git tools, the lack of explicit exclusions or alternative references keeps it just 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.