linux-mcp
Server Quality Checklist
Latest release: v0.2.13
- Disambiguation5/5
Each tool targets a distinct subsystem or metric, with clear descriptions that separate potentially overlapping tools (e.g., get_docker_container_stats vs get_docker_stats_all vs get_docker_system_snapshot). No two tools appear to do the same thing.
Naming Consistency5/5Almost all tools follow the consistent get_<noun> pattern, making the tool's purpose predictable from its name. The few exceptions (check_updates, ping_host, resolve_dns) still use a clear verb_noun structure and do not disrupt the overall pattern.
Tool Count1/562 tools is far beyond what is typically appropriate, even for a broad system monitoring server. The huge number creates excessive cognitive load for agents, and many tools could be consolidated (e.g., the 12 Docker-specific tools could be grouped into fewer tools). This is an extreme mismatch.
Completeness4/5The toolset covers most major system monitoring areas including CPU, memory, disk, processes, Docker, security, logs, and systemd. However, it lacks a tool for listing network interface IP addresses or routing table, which is a common requirement for network troubleshooting.
Average 4.6/5 across 62 of 62 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 137 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 28 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- 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 states 'Read-only via the Docker API', which is a key behavioral trait. It also clarifies the temporal scope ('since it started'). However, it does not disclose potential error cases or permission requirements, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. It front-loads the core function and immediately follows with usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple one-parameter schema and an output schema, so the description does not need to explain return values. It covers the core behavior and usage. It could mention prerequisites like Docker daemon access, but that is a common assumption. Overall, it is complete enough for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for container_id, so the baseline is 3. The description does not add any extra meaning about the parameter beyond what the schema already provides (e.g., it does not mention that it accepts names or IDs, which the schema already states).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' with a clear resource ('filesystem changes in a container') and scope ('since it started'), listing the types of changes (added, modified, deleted). It clearly distinguishes from sibling tools like get_docker_container_logs or get_docker_container_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use to see what a container wrote to its writable layer' provides clear usage context. It implies when to use this tool, though it does not explicitly mention alternatives or exclusions. The context is sufficient for a single-purpose read-only tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of safety and behavior. It states 'Read-only' and discloses failure conditions ('fatal only if systemd-analyze is missing or fails'). It also explains the optional unit parameter's effect, adding meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff, front-loading the core function and then adding parameter and safety notes. Every sentence earns its place, making it efficiently scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param) and has an output schema, so return values are covered. The description covers purpose, usage, parameter behavior, and error conditions, making it complete for this read-only diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage for the single parameter, including a description. The tool description adds a brief restatement ('Optional unit param starts the chain from a specific unit') but no new semantic detail, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('time-critical boot chain from systemd-analyze critical-chain'), and clarifies it's a dependency tree with active-time and duration. This clearly differentiates it from siblings like get_boot_blame or get_boot_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'Use to find what delays the boot target.' It implies when to use this tool, though it doesn't explicitly exclude alternatives. This is sufficient context for the agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses 'Read-only via the Docker API' (safe operation) and 'fatal if the daemon is unreachable or the container is unknown' (error behavior). This is valuable beyond the schema, though it doesn't detail output structure or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds useful information (purpose, safety/error characteristics, use case). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need not be explained. The description covers purpose, read-only nature, fatal error conditions, and a use case, making it sufficiently complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both container_id and args described in the input schema. The description itself adds no parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns the processes running inside a container', which is a specific verb+resource combination. It distinguishes from siblings like get_docker_container_details and get_docker_container_stats by focusing on process-level information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a direct use case: 'Use to debug container-level process state.' However, it does not explicitly mention when not to use it or point to alternative tools, so it provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden. It discloses external call to ip-api.com, network dependence, potential slowness offline, and error behavior for invalid IPs. Good coverage of key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the primary function, then add caveats and use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with one optional param and existing output schema for return structure, description fully covers purpose, behavior, and context. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description identical to tool description ('defaults to your public IP'). No additional parameter-level insight provided; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Returns' and resource 'IP', listing exact data types (geolocation, ASN/organization, provider tags). Clearly distinct from sibling tools like ping_host or resolve_dns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States intended use case ('network egress and remote-peer context') and caveat about network dependency. Does not explicitly mention alternatives or when-not-to-use, but context is sufficient given uniqueness among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 operation is read-only via /proc/<pid>/fd, and it states that an unknown pid returns an error in the errors field rather than a failure. This is meaningful behavioral context beyond the schema, though it does not cover permission-related edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function, followed by a specific use case. Every sentence contributes meaningful information, with no redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 the what, how, error behavior, and recommended use case. It is complete enough for an agent to select and invoke the tool correctly without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the pid parameter already has a clear description ('process ID to list open file descriptors for'). The tool description reinforces that pid is required but adds no additional parameter-level semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lists open file descriptors (files, sockets, pipes) and the total count for a pid,' which is a specific verb+resource. It clearly distinguishes from sibling tools like get_file_locks or get_network_connections by enumerating the exact resource types covered and including the count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for fd-leak and resource-hold debugging,' providing a clear when-to-use context. It does not name alternative tools, but the tool's purpose is sufficiently unique among siblings that explicit exclusions are less necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 'Read-only' and discloses that a passwd read failure is non-fatal, which is valuable safety-related context. It also mentions the case-insensitive substring behavior for the search parameter. It does not detail every edge case, but for a simple read-only query tool, this is strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of four short, purposeful sentences. Each sentence adds distinct value: what it lists, search behavior, read-only/failure mode, and intended use. There is no redundant fluff, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and an output schema present, the description covers all necessary aspects: purpose, behavior, failure handling, and usage intent. It does not need to explain return structure since the output schema exists. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the search parameter as 'optional username filter (case-insensitive substring match)', and the description repeats this almost verbatim ('search does a case-insensitive substring match'). Since schema coverage is 100% and the description adds no new meaning beyond the schema, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Lists system users') and identifies the exact data sources ('/etc/passwd and /etc/group') with the fields returned (username, UID, GID, home, shell, supplementary groups). This clearly distinguishes it from sibling tools like get_logged_in_users or get_user_automation, which target different aspects of user information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use for account inventory and membership checks.' This tells the agent when to select this tool. However, it does not mention alternatives or cases where it should not be used (e.g., when you only need currently logged-in users), so it stops 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full responsibility for behavioral disclosure. It accurately states the operation is read-only (os.Environ), describes redaction of sensitive names (SECRET, TOKEN, PASSWORD) to '***', and notes the sorted output format, providing substantial transparency beyond the bare function. No annotations contradict this information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized with multiple short sentences, each conveying a distinct piece of information: return type, filtering behavior, read-only nature, redaction policy, and use case. It is slightly redundant with the schema regarding the search filter, but overall it is compact and well-structured without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, read-only operation) and the presence of an output schema, the description covers all essential context: what is returned, how to filter, safety/redaction, and typical use cases. No critical information is missing for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the single 'search' parameter already fully explains that it filters by name prefix or substring, case-insensitively. The tool description repeats this same information, adding no new semantic value beyond the schema. With 100% schema coverage, a 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the server process's environment as a sorted key-value map, which is a specific verb and resource. It is distinct from sibling tools that focus on other system aspects like networks or CPU, with no ambiguity about what this tool offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by suggesting 'Use to debug PATH, locale, and server configuration,' which tells the agent when this tool is appropriate. However, it does not explicitly mention when not to use it or name any alternative tools, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It reveals key behavioral traits: read-only operation, exclusion of Boot records, use of lastb with fallback to journalctl, default entry count, and non-fatal errors. While it doesn't mention auth requirements or response format details, the disclosure is strong for a simple read-only 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three sentences total—yet packs in purpose, exclusions, read-only nature, fallback mechanism, default, error handling, and usage guidance. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core aspects: what the tool returns, what it excludes, how it acquires data, error behavior, and when to use it vs. an alternative. Given the simple one-parameter schema and presence of an output schema, this is quite complete. Minor omission is lack of detail about 'summary statistics', but that is likely covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'lines', which already describes its purpose and default. The description adds minimal new meaning beyond confirming the default ('Default 20 entries') and hinting at the parameter via 'lastb -n N'. This is sufficient given the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and clearly identifies the resource ('recent failed login attempts') with a scope qualifier ('excluding Boot records'). It also explicitly distinguishes itself from a sibling tool ('get_audit_logs for kernel and auditd events'), so purpose clarity is excellent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use for security triage') and names the alternative for other use cases ('get_audit_logs for kernel and auditd events'). It also provides context about the read-only nature and fallback behavior, giving clear guidance on expected behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 the tool is read-only and that it is fatal if the chosen source is unavailable, which warns about error conditions. It does not mention permissions or output formatting, but the output schema likely covers return values, so the description adds meaningful behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by parameter defaults and usage guidance. Every sentence adds distinct value, and the alternative tool is mentioned efficiently. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 simple parameters and an output schema, the description is complete. It covers purpose, sources, parameter defaults, error behavior, and use cases, while also pointing to a sibling tool for related needs. The output schema handles return-value details, so no additional explanation is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters (lines and source) have descriptions specifying defaults and allowed values. The description restates the same information ('source param: journalctl, audit.log, or auto (default). lines defaults to 50') without adding new semantic depth, so it provides no added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns kernel audit events from specific sources (journalctl -k or /var/log/audit/audit.log) with examples of event types (AVC denials, system calls). It explicitly distinguishes from sibling tool get_failed_logins by directing users to that tool for login attempts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context ('Use for security forensics') and an explicit alternative ('get_failed_logins for login attempts'). It also cautions about fatal behavior when the source is unavailable, which helps agents decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 read-only access, the data sources (/proc/stat and /proc/cpuinfo), and the fatal condition (unreadable source). This is meaningful behavioral disclosure beyond just saying 'read-only.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the return values, followed by read-only nature, fatal condition, and use case. Every sentence contributes meaning with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters) and has an output schema, so return format coverage is handled. The description covers purpose, data sources, fatal behavior, and usage context, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description adds context about the tool's internal behavior (reading from specific proc files) but does not need to document parameters. Baseline 4 for no parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns CPU model, frequency, core count, and current usage percent.' The verb 'Returns' plus the resource (CPU) and specific output fields make it distinct from siblings like get_cpu_temperature and get_load_average.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use for capacity planning or busy/idle checks.' While it does not name alternatives or explicitly say when not to use, it provides clear applicable scenarios, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the read-only nature ('Read-only via the Docker API') and failure conditions ('fatal if the daemon is unreachable or the container is unknown'), which are important behavioral traits. It doesn't mention permissions or other edge cases, but for a read-only inspection tool, this covers the key risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: outlining the return content, disclosing behavior, and providing usage guidance. It is concise, front-loaded with the core function, and contains no irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and an output schema, so the description does not need to describe return values in detail. It covers purpose, usage, behavior, and failure modes, making it sufficiently complete for an agent to select and invoke the tool correctly. The distinction from get_docker_info adds important context within the sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter, container_id, as 'container name or ID' (100% coverage). The description does not add additional parameter semantics beyond what the schema already provides, so 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns a container's state, config, env, mounts, and network settings.' It uses a specific verb and resource, and explicitly differentiates from get_docker_info by noting 'Use to inspect one container; get_docker_info to list them.' This makes the purpose unmistakable and distinguishes it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use to inspect one container; get_docker_info to list them.' This tells the agent when to use this tool (inspecting a single container) and when to use an alternative (listing containers). It effectively communicates both the intended use and the boundary with a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. It discloses that the operation is read-only, describes fatal error conditions (daemon unreachable or unknown container), and notes that environment values are redacted. This goes beyond the schema and provides critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with the purpose. Each sentence adds value: what it returns, key params, read-only/error behavior, and redaction. No waste or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple log retrieval tool. It explains the output (log lines), key behaviors (read-only, fatal errors, redaction), and relies on the existing output schema for return structure. Given the low complexity and good annotation coverage, no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 mentions 'tail (line count) and timestamps' but this simply repeats what the schema already documents. It adds no additional parameter semantics, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Returns a container's stdout/stderr log lines.' It distinguishes this from sibling Docker tools (e.g., stats, top, details) by focusing on log retrieval, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for use is clear: use this to retrieve container logs. It doesn't explicitly name alternatives or when-not scenarios, but the description's focus on log lines and the sibling tool names make the intended usage obvious. A score of 4 is appropriate for clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description explicitly discloses 'Read-only via the Docker API,' informing the agent that this is a safe read operation. It also discloses the output categories, providing useful behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose and breakdown, followed by usage guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters) and the presence of an output schema, the description covers purpose, usage, and read-only nature completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so parameter information is not needed. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Returns') and a specific resource ('Docker disk usage') with a clear breakdown by containers, images, volumes, and build cache. This clearly distinguishes the tool from siblings like get_docker_volumes or get_docker_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use to find what is consuming disk space.' It provides clear context but does not mention exclusions or alternative tools, so it falls short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explicitly states 'Read-only via the Docker API', a key safety trait, and implies an external Docker dependency. This goes beyond what the tool name alone would convey, though it could mention error behavior or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three crisp sentences, each serving a purpose: functionality, read-only safety, and usage guidance with a fallback tool. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, read-only operation) and the presence of an output schema, the description covers all essential aspects: what it returns, its safety, when to use it, and how it differs from a sibling tool. It is fully adequate for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter image_id is fully described in the schema as 'image name or ID'. The description adds no further parameter semantics, but since schema coverage is 100%, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns an image's layer history: commands, sizes, and creation times' — a specific verb and resource. It also distinguishes itself from the sibling get_docker_image_details by mentioning it for config and labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use to understand what an image is built from'. It also directs users to get_docker_image_details for a different need, clearly differentiating the tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 of behavioral disclosure. It explicitly states 'Read-only via the Docker API', which is a key safety trait. While it does not mention permissions or failure modes, this is adequate for a simple read-only API call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. Each sentence adds value: what it returns, its safety model, and its intended use case. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description covers the essential aspects: purpose, read-only behavior, and use context. Nothing else needs to be explained for a simple listing utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so no parameter ambiguity exists. The baseline score of 4 for zero-parameter tools applies here, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns Docker networks with driver, scope, and configuration details. The verb 'Returns' and resource 'Docker networks' are specific, and this tool is clearly distinct from sibling tools targeting containers, images, volumes, or system information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends use for network topology debugging, providing a clear usage context. It does not mention alternatives or exclusions, but for a zero-parameter read-only listing tool, this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is read-only and one-shot, which are important behavioral traits. However, it does not mention potential performance impacts or any error conditions, though the simple nature of the tool mitigates this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: what it returns, the optional filter, and when to use it. It is front-loaded and concise with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description covers the purpose, the filter, usage context, and safety profile. No critical information is missing given the presence of the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'containers' is fully described in the schema (100% coverage). The description adds no new meaning beyond restating that it filters by name or ID, so it provides minimal added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns CPU, memory, network, and block I/O for all running containers. It explicitly distinguishes itself from the sibling get_docker_container_stats by positioning as a fleet overview alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use instead of repeated get_docker_container_stats calls for a fleet overview.' This tells the agent when this tool is appropriate and names the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it discloses 'Read-only via the Docker API' and 'fatal if the daemon is unreachable.' This is valuable operational context that goes beyond a generic 'get info' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function, and includes a use case and operational caveat. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 covers purpose, specific data returned, read-only nature, and a fatal failure condition. It is fully sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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, but none are needed; it correctly focuses on the tool's output and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and resource ('Docker daemon info'), enumerating concrete fields (version, storage driver, runtimes, resource counts). This distinguishes it from sibling tools like get_docker_info, which may be broader, and clearly states 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use to check daemon config and health,' providing a clear use case. However, it does not mention alternatives or when-not-to-use, so it stops short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the read-only nature, the underlying commands (lspci/lsusb with sysfs fallback), and error behavior ('if both fail the error goes in the errors field'), adding significant transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences, each serving a distinct purpose: function, method/error handling, and usage guidance. No filler or redundant wording, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema (as indicated), the description sufficiently covers purpose, method, error handling, and use case. The presence of an output schema means return values are already documented, so no additional explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'search' parameter, so the baseline is 3. The description repeats the schema's mention of filtering by fields, adding no new semantic detail 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and specific resources 'PCI and USB devices detected on the system.' It is distinct from sibling tools like get_cpu_info or get_disk_info, uniquely covering hardware bus devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use to identify network cards, audio interfaces, and expansion cards for driver troubleshooting.' While it doesn't name alternatives or exclusions, the context is clear and there are no overlapping siblings that would require differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses safety ('Read-only') and failure behavior ('fatal if df is missing or fails'). This is valuable behavioral context beyond the schema, though it could also mention if any 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. Each sentence earns its place: functionality, parameter semantics, and usage guidance are all front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, output schema exists). The description covers purpose, usage, parameter behavior, and failure mode, 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description enhances parameter meaning by calling mount_point an 'optional exact filter', clarifying it matches exactly rather than partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a specific verb 'Returns' and identifies the resource as 'inode usage per filesystem via df -i'. It clearly distinguishes from siblings like get_disk_info by scoping to inode usage and mentioning 'inode exhaustion'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a usage scenario: 'Use when disk full errors persist despite free space - inode exhaustion.' This is clear context, though it does not mention when NOT to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It explicitly declares 'Read-only' and warns that the operation is 'Fatal if the package manager is unsupported or the query fails,' which are important operational caveats. It does not mention any permission requirements, but the read-only nature and failure modes are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is two sentences, front-loading the primary action and supported systems, followed by usage guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description covers the essential operational context: what the tool does, which system families it supports, its read-only nature, failure behavior, and a pointer to the alternative for upgrades. This is sufficient for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter with 100% coverage ('optional package name filter'), and the description echoes 'Optional name filter.' No additional semantic detail such as regex or exact-match behavior is provided, so the description adds only minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Queries installed packages' and names the exact package manager commands for Arch and Debian, making the tool's function unambiguous. It also differentiates from sibling tool check_updates by specifying this is for checking what is installed, not for upgrades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides direct usage guidance: 'Use to check what is installed; check_updates for available upgrades.' It also states both supported package managers (pacman, dpkg) and unsupported ones (rpm/dnf), giving the agent a clear precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool is read-only via journalctl, notes failure conditions (journalctl failure or invalid unit), and describes the return structure. This goes beyond the schema, though it doesn't mention potential permissions or large output constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with each sentence covering a distinct aspect: purpose, filters, user flag, safety/failure, return format, and alternative. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with six optional parameters and an output schema, the description effectively covers all necessary context: what it does, when to use it vs. alternatives, failure behavior, and return content. It is sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all parameters (100% coverage). The description adds a usage note for the 'user' parameter and summarizes filtering options, but this is supplementary rather than essential since the schema covers parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads systemd journal entries, with specific verbs and resource identification. It also distinguishes itself from a sibling tool by noting 'For kernel-only events use get_audit_logs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides usage guidance, including when to use the alternative tool for kernel-only events. The instruction 'Set user=true for the user journal' gives concrete invocation context, clarifying a key parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 states the operation is read-only, specifies the source paths (/etc/logrotate.conf and /etc/logrotate.d), and mentions error handling ('Errors land in the errors field'). This is substantial, though it could add what happens if files are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the purpose and sources; the second covers error behavior and usage. Every sentence earns its place, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, no-parameter tool with an output schema, the description is complete: purpose, sources, read-only nature, error handling, and use case. The output schema likely covers return values, so no need to explain them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. No parameter information is needed, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returns logrotate configuration files and the state file path. It uses a specific verb ('Returns') and resource, and differentiates itself from sibling system-info tools by focusing on logrotate-specific details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use to verify rotation policies.' It also clarifies the read-only source paths, giving clear context. However, it does not mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the read-only mechanism ('Read-only via man -P cat'), validation ('command is required and validated'), error behavior ('Fatal if man is missing or there is no manual entry'), and option effects ('max_lines ... with a truncated flag, case-insensitive search with context_lines, and offset').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that front-load the core purpose, follow with option summary, and end with usage guidance. No filler; each sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no annotations, the description covers purpose, usage, error behavior, and option effects. The output schema exists, so return values are documented there. The description is comprehensive enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the baseline is 3. The description partially repeats schema details (e.g., max_lines range, case-insensitive search) but does not significantly add new meaning beyond grouping options. It does not explain 'clean_special_chars' beyond the schema, though the schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetches the authoritative man page for a command as plain text' with a specific verb and resource, and clarifies usage 'when the user asks about flags, syntax, or edge cases.' This clearly distinguishes it from the sibling system-info getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description ends with 'Use when the user asks about flags, syntax, or edge cases,' providing explicit context. It lacks an explicit 'when not to use' or named alternatives, but the sibling tools are all system information retrievers, making the intended domain clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Read-only' which is a key safety trait, and it discloses error behavior: 'Missing sysfs data lands in the errors field.' This adds valuable behavioral context beyond the basic return value list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each providing essential information: what is returned, the data source and safety, error handling, and a usage recommendation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no params and an output schema exists (which covers return values), the description is complete. It explains what data is retrieved, where from, error behavior, and typical use case. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (empty schema), so the baseline is 4. There is nothing to add beyond the schema; the description appropriately focuses on behavior rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns power state (AC vs battery), discharge rate in watts, battery percentage, and capacity degradation. This is a specific verb ('returns') with a clear resource (power analytics), and it distinguishes itself from sibling tools which cover different system resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use for laptop power monitoring.' It also specifies the data source (/sys/class/power_supply), giving context on when this tool is appropriate. It does not explicitly name alternatives or exclusions, but since no sibling tool handles power data, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It explicitly states 'Read-only' which conveys a key safety trait, and explains per-section failure handling ('per-section failures land in the errors field'). This goes beyond a vague 'gets data' and gives the agent confidence about side-effect-free execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences total, front-loaded with the primary function, and every sentence adds useful information (what, how to filter, safety/error behavior). No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers the essential aspects: return content, selection mechanism, safety, and error strategy. The output schema is present, so no need to describe return fields. It adequately prepares the agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description repeats the schema's parameter guidance about comma-separated sections and empty=all, but adds no new information beyond what the input schema already documents. Since schema coverage is 100%, the baseline of 3 applies; the description does not deepen the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Returns deep /proc diagnostics' and enumerates exact sections (interrupts, softirqs, etc.). It distinguishes itself from the many sibling get_* tools by explicitly framing this as a bundle of /proc diagnostics for kernel-level debugging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives explicit usage context: 'Use for kernel-level debugging.' While no alternatives are named, this clearly positions the tool for broad kernel diagnostics rather than specific resource queries. The comma-separated subset hint also tells when to use it for selected sections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It openly discloses the read-only nature and the silent swallowing of an unreadable file, which is important failure behavior. This goes beyond a generic read tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary function. Every clause carries useful information: data source, fields returned, read-only, failure behavior, and use case. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and no parameters, the description covers the essential context: what data is returned, the read-only nature, the failure mode, and the recommended use case. It is complete for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage. The description adds context by mentioning the source file (/proc/mdstat), which is the only implicit input. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns software RAID status from /proc/mdstat, listing specific data types (devices, levels, sizes, health). This distinguishes it from sibling tools like get_disk_info or get_block_devices, which cover broader or different storage aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to check array health', which gives a clear context. It does not name alternatives or exclusions, but for a small read-only status tool with zero parameters, this is sufficient to direct appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full responsibility of behavioral transparency. It discloses that the tool is read-only, never fatal, and reports 'not_enabled' for missing modules. These are valuable behavioral insights, though it could mention potential return formats or error handling beyond what is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the purpose, the second provides behavioral guarantees, and the third gives usage context. Each sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters) and the presence of an output schema, the description provides sufficient context: purpose, usage, and behavioral traits. There are no gaps that would hamper an agent's ability to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The baseline for 0-param tools is 4, and the description adds contextual info about the underlying implementation (getenforce and sysfs/aa-status) that is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns SELinux and AppArmor enforcement status.' It uses a specific verb with a well-defined resource, and the focus on security posture distinguishes it from other get_* tools like get_security_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use for security posture checks.' It provides clear context but does not mention alternatives or exclusions, 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.
- 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 disclosing behavior. It states the operation is read-only and that an unreadable file is silently swallowed, which is useful behavioral context. It does not mention possible permission issues or error handling beyond that, but the core traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every word adds value. It efficiently conveys source, content, behavioral notes, and use cases without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description provides adequate context: the source file, the data fields returned, read-only behavior, and recommended use cases. It is complete for a simple diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description has no need to explain parameter behavior. The baseline for zero-parameter tools is 4, and the description sufficiently covers what the tool does without needing to clarify inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: returns System V shared memory segments from /proc/sysvipc/shm, and lists the specific data fields (key, size, attached processes, timestamps). It distinguishes itself from sibling diagnostic tools by its specific focus on shared memory segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly identifies when to use this tool: 'Use for IPC and leak investigation.' This provides clear context for use, though it does not mention when not to use it or suggest alternatives, making it slightly less complete than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that lookup failures appear in the errors field and that the tool is network-dependent. This is sufficient for a simple resolver, though it could mention timeout behavior or multiple IP formatting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every sentence adds useful information. No redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter network tool, the description covers purpose, usage, failure behavior, and environmental dependency. An output schema exists, so return values are documented elsewhere. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds that hostname is required (redundant with schema) and relates failure behavior to the parameter, but no new parameter-level semantics beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Resolves a hostname to IP addresses via the system resolver,' which clearly states the action and resource. It explicitly contrasts with ping_host, distinguishing its purpose from 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: 'Use to distinguish DNS failures from connectivity problems; ping_host to test reachability.' This states when to use this tool and when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/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 states the tool is read-only and mentions the only fatal condition (systemd-analyze missing or failing), which is valuable behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence packs the core functionality and output details, while the second covers safety and use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return content (phases, total time, target), the tool's source (systemd-analyze), the failure mode, and the intended use. Given that an output schema exists, the description is sufficiently complete for this simple, zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). The baseline for 0 params is 4, and the description adds useful context about the tool's output rather than needing to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the boot-time breakdown from systemd-analyze time, listing specific phases (firmware, loader, kernel, initrd, userspace), total time, and target. This concrete verb+resource phrasing distinguishes it from sibling tools like get_boot_blame and get_boot_critical_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use to quantify where boot time goes.' It does not mention when not to use or name alternatives, but the context is clear and non-misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses read-only behavior and the graceful fallback where a message is returned in the errors field instead of failing. It does not cover output details, but an output schema exists and the fallback behavior is a key non-obvious trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose, then read-only status, fallback behavior, and usage guidance. Every sentence adds value with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only sensor tool with an output schema, the description covers purpose, usage scenario, alternative tool, and error handling. No additional context is needed for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, a baseline of 4 applies because there are no parameter semantics to explain, and the description correctly avoids fabricating param-related detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current CPU temperature from hwmon sensors, which is a specific verb (returns) plus resource (CPU temperature). It also distinguishes itself from the sibling get_system_health_check by noting it provides raw temperature data rather than an overall verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use for thermal monitoring; prefer get_system_health_check for an overall verdict.' This tells the agent when to choose this tool and explicitly names an alternative for a different scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and does so excellently: it states the tool is read-only from environment variables and never fails. This directly informs the agent about safety and reliability without needing separate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states what it returns, the second covers behavior and usage. Every word earns its place; it is front-loaded with the core purpose and includes no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is complete: it explains purpose, behavior, and when to use it. Nothing relevant is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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-specific details because none exist, which is appropriate. The schema coverage is vacuously 100%, and the description focuses on output and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns display protocol (Wayland/X11), desktop environment, and related environment config. The verb 'returns' and specific resource make the purpose unmistakable, and it is distinct from the many other get_* 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit use case: 'Use to understand the GUI session the server runs under.' It does not explicitly mention alternatives or when not to use, but the context is clear and sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It discloses that the tool is 'Read-only via statfs,' which signals safety, and details error handling: 'Fatal only if partitions cannot be listed; per-partition read errors are skipped.' It also adds parameter constraints ('exact match, must start with /'). This is rich behavioral context, though it could mention the output format, but an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, followed by parameter details, error behavior, and usage guidance. Every sentence adds information, with no filler or redundancy. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the core function, parameter semantics, error behavior, and even provides an alternative tool. The output schema is present, so return value documentation is not needed. The description is self-sufficient 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/5Does 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 meaning beyond the schema: mount_point requires 'exact match, must start with /' and threshold means 'only partitions at or above it.' These clarifications are valuable and make parameter usage clearer than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Returns disk usage per mounted partition.' It uses a specific verb ('Returns') and resource ('disk usage per mounted partition'), and it distinguishes itself from sibling tools by contrasting with get_inode_usage. This is a clear, specific purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use for capacity; get_inode_usage when "disk full" persists with free space.' This names an alternative tool for a specific scenario, making when-to-use and when-not-to-use clear. It also frames the tool as a capacity monitoring tool, which is useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states 'Read-only, one-shot sample' and 'Stats only exist for running containers; unknown or stopped ids error', providing key operational expectations without need for digging into schema or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff. It front-loads the core purpose, then covers parameters, behavior, and an alternative in a tight, structured manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter, an output schema exists, and the description covers usage, errors, read-only nature, and alternatives. Nothing important is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains container_ids as 'container name(s) or ID(s), comma-separated, or 'all' for all running containers'. The description adds only minor clarification ('running only', 'unknown or stopped ids error'), which is more behavioral than parameter-level semantics. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live CPU, memory, network I/O, and PID stats for running containers. The verb 'Returns' with a specific resource and scope distinguishes it from sibling tools like get_docker_container_details or get_docker_container_top.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to 'use get_docker_stats_all' for all containers in one call, an alternative. It also clarifies when to use this tool (for specific containers or 'all' running) and notes that unknown or stopped ids error, guiding appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool is read-only via the Docker API and discloses fatal conditions (daemon unreachable, unknown image), which is valuable operational context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the core function, the second adds behavioral caveats, the third provides usage guidance and sibling reference. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers what the tool returns, error conditions, read-only nature, and when to use it. It is fully complete given the richness of the schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter image_id with the description 'image name or ID', so schema coverage is 100%. The tool description adds no additional parameter-specific meaning beyond implying the image to inspect, so 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an image's config, env, entrypoint, labels, and layers, using the specific verb 'Returns' with a well-defined resource. It differentiates from the sibling tool get_docker_image_history, which is for build steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool to inspect a single image and directs users to get_docker_image_history for build steps. This provides clear when-to-use guidance and names the alternative, making it easy for an agent to select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that the tool is read-only via Docker API and is fatal if the daemon is unreachable, which are important behavioral traits. It does not mention limits or pagination, but for a simple inventory read, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it immediately states the main output, then adds safety and error behavior, and finishes with usage guidance. Every sentence provides value and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and presence of an output schema, the description is complete. It specifies the scope of returned data, read-only guarantee, failure mode, and appropriate usage, making it well-rounded for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics since there are none. The empty schema is fully covered, and the description adds context about what is returned rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Docker containers (including stopped) and images, using specific verbs and resources. It distinguishes itself from siblings by highlighting 'including stopped' and aligning with 'Docker inventory' while pointing to get_docker_system_snapshot for a fuller view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for a Docker inventory; get_docker_system_snapshot for a fuller view,' providing direct when-to-use guidance and naming an alternative. It also notes the read-only nature and fatal failure condition, which helps selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description disclosures essential behavioral traits: read-only via Docker API, per-part failures land in the errors field while the call still succeeds, and it is the heaviest Docker call. This goes beyond the bare minimum, though it does not cover potential pagination, rate limits, or authorization details, which would be valuable for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: a clear functional summary, a key behavioral caveat, and a usage recommendation. Each sentence adds distinct value with no redundancy or filler. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations, the description covers the tool's purpose, safety (read-only), failure semantics, and performance tradeoffs. Since an output schema exists, the description does not need to list return fields. It provides complete context for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meanings. Per the baseline for 0 params, a score of 4 is appropriate. The description appropriately mentions the errors field in the output, which indirectly hints at the output shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Returns a combined Docker snapshot') and enumerates its contents (containers, images, running stats, disk usage, networks). It clearly distinguishes itself from sibling get_docker_* tools by framing itself as a combined/heavy snapshot, which is a distinct scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence explicitly states when to prefer this tool: 'Heaviest Docker call - prefer narrower get_docker_* tools for a specific question.' This gives clear alternatives and a performance-based criterion for choosing this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses 'Read-only via the Docker API', a key behavioral trait. It also specifies returned data fields. For a zero-parameter read operation, this is sufficient, though it doesn't mention potential errors or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the return type and fields, second notes read-only nature and usage guidance. Efficient, front-loaded, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only inventory tool with an output schema, the description covers purpose, safety profile, and sibling differentiation. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters, so baseline is 4. Description adds no parameter details (none needed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Returns Docker volumes with driver, mountpoint, size, and labels' – a specific verb and resource with listed fields. It also differentiates from sibling get_docker_disk_usage by noting that tool for space accounting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use to inventory storage; get_docker_disk_usage for space accounting' – gives a clear use case and names an alternative for a related but distinct purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly notes that the tool is read-only, that unreadable files are silently swallowed, and that parse errors go into the errors field. This transparency goes beyond a simple return statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function and output fields, the second adds the use case and behavioral caveat. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 is complete. It covers the data source (/proc/locks), output fields, error handling, and intended use case, leaving no gaps 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivial. The description adds meaningful context by enumerating the output fields and error behavior, which helps the agent understand what data will be returned. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it returns active file locks from /proc/locks, enumerating the specific fields (type, mode, PID, byte range, path). It also states the tool's purpose ('Use to find who holds a lock'), distinguishing it from sibling get_* tools by focusing exclusively on file locks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear, direct use case: 'Use to find who holds a lock.' This provides clear context for when to use the tool. It does not explicitly mention when not to use it or alternatives, but the use case is sufficient for a read-only diagnostic tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 and excels. It discloses the read-only nature, the backend tool fallback order (nvidia-smi, rocm-smi, intel_gpu_top), fatal failure only when no GPU tool exists, and the critical Intel fallback limitation (presence only, not metrics).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each earning its place: purpose, safety/backend, failure behavior, fallback limitation, and usage guidance. Front-loaded with the main functionality; zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 (which handles return-value details), the description covers everything else: what it returns, safety, backend selection, failure mode, fallback caveat, and use case. No meaningful gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per rubric baseline is 4. The description correctly omits parameter details since there are none to explain; the empty schema requires no compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns GPU usage, memory, temperature, and power draw.' This precisely states what the tool does and clearly differentiates it from siblings like get_cpu_info and get_memory_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence, 'Use for GPU workload monitoring,' provides explicit when-to-use context. However, it does not name alternatives or state when not to use this tool, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 disclosing behavioral traits. It states the tool is read-only, fatal if ss is missing, and that process names may be empty without root privileges. These are important operational caveats that go beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with every sentence providing essential information: what it returns, the command used, filter behavior, safety, error condition, and usage guidance. No superfluous content, and key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema, the description sufficiently covers all necessary context: purpose, invocation caveats, and when to use it. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the protocol parameter with 100% coverage, and the description simply restates the filter behavior ('protocol filters to tcp or udp'). Since the schema does the heavy lifting, the description adds minimal new semantic value, consistent with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns listening TCP/UDP ports and associated processes via ss -tulnp, with a specific verb and resource. It also distinguishes itself from get_network_connections by noting that the latter is for established connections, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use for port-conflict and exposure checks' and explicitly names the alternative for established connections (get_network_connections). This gives clear direction on when to use this tool versus a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 operation is read-only, sourced from '/proc/loadavg', and that it is 'fatal only if unreadable' – providing concrete error behavior. However, it doesn't describe the output shape or any potential side effects, though output schema exists to cover returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause earns its place. It efficiently covers purpose, source, safety, and usage alternative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 covers the essential context: what it returns, when to use it, the data source, and failure mode. This is 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, and the baseline for 0 params is 4. The description adds no parameter details because there are none to add; there is no risk of ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns 1-, 5-, and 15-minute load averages.' This clearly differentiates it from sibling tools like get_cpu_info and get_system_health_check by focusing on load averages. The mention of '/proc/loadavg' further specifies the source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use as a quick utilization check' and names an alternative: 'get_system_health_check compares load against core count.' This provides both a clear when-to-use and directs the agent to an alternative when core comparisons are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's safety profile ('Read-only') and its only failure condition ('fatal only if who is missing'). It also names the underlying command, which aids transparency. This exceeds the minimum burden without 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then provides safety and usage context. Every sentence earns its place, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description covers purpose, fields returned, safety, failure condition, and use cases. It is complete for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description adds no parameter-specific information because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns active user sessions via `who -u` with specific fields (username, terminal, origin, login time). This is a specific verb+resource that immediately distinguishes it from sibling tools like `get_user_info` or `get_failed_logins`, which target different aspects of user accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear use cases ('security awareness and multi-user workload checks'), giving context for when to invoke. However, it does not explicitly mention when not to use it or name alternatives, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and covers key behavioral aspects: it discloses read-only access from /proc/meminfo and the single fatal error condition. It could also mention potential non-fatal issues or output formatting, but for a simple read-only tool, this is sufficient and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences: first states the primary purpose, second covers safety/source, third provides usage guidance. No filler or redundant information, and the most important information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present), the description covers all essential context: what it returns, where it reads from, and when to use it. The existence of an output schema means return format doesn't need to be detailed here, so the description is 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter syntax, but it adds context by indicating the output fields (total, used, free), which helps the agent understand expected data without reference to the parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns RAM and swap usage with total, used, and free values, specifying a concrete verb and resource. It also differentiates from sibling tools by referencing get_system_health_check for threshold checks, making the tool's specific 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use for memory pressure checks; get_system_health_check for thresholds.' This not only indicates when to use this tool but also names an alternative for a related but distinct need, fulfilling the when/when-not distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full burden of behavioral disclosure. It states the tool is read-only and fatal if findmnt is missing, which are critical safety and error traits. It also clarifies mount_point filters to an exact target, adding useful behavioral nuance. It does not mention permissions or output size, but given the simple read-only nature and output schema, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of four short, purposeful sentences: what it returns, how the parameter works, safety/failure, and when to use it vs. the alternative. No unnecessary words, and the primary action is stated first, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description covers all essential aspects: purpose, usage, safety, error condition, parameter behavior, and alternative tool. It is fully adequate for an agent to select and invoke the tool correctly without needing additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers mount_point with 100% coverage, but the description adds an important semantic: 'filters to an exact target'. This clarifies that matching is exact rather than substring or partial, which goes beyond the schema's basic description and gives the agent a precise understanding of the filter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns mount sources, targets, filesystem types, and options via findmnt, with a specific verb and resource. It distinguishes from siblings by explicitly naming get_disk_info as the alternative for usage queries, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use for mount flags (rw/ro, noexec, etc.)' and names get_disk_info as the alternative for usage. This provides clear selection criteria and helps the agent decide between this tool and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the read-only nature via '/proc/net' and the performance cost of reverse DNS lookups, which is valuable behavioral context. However, it does not mention any permission requirements or edge cases, leaving some room for additional detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with essential information: purpose, data source, parameter highlights, performance caveat, and an alternative tool reference. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the core function, source, performance implications, alternates, and all parameters are documented in the schema. The output schema exists, so return format need not be detailed. This is a complete and well-rounded description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context beyond the schema by summarizing filters, grouping, and max_connections range (0-200), and by highlighting that resolve_hostnames performs slow network lookups. This enriches parameter understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns active TCP/UDP connections with state, addresses, process info, and optional reverse-DNS hostnames. It explicitly differentiates from the sibling get_listening_ports by advising its use for listening sockets, making the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'For listening sockets prefer get_listening_ports' and warns that resolve_hostnames is slow and should be kept off unless needed. This gives clear context on when to use this tool versus an alternative and how to use parameters safely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It states the tool is read-only, reads from /proc/net/dev, and only fails if that file is unreadable. This is solid behavioral context, though it doesn't describe the return format edge cases like no interfaces present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, purposeful sentences: first states what it returns, second adds source and failure mode, third gives usage guidance. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, and the description covers the key aspects: return value content, data source, read-only nature, failure condition, and usage context. For a simple no-parameter tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so a baseline of 4 is appropriate. The description communicates that no arguments are needed, and the schema confirms no properties, so nothing more is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Returns' and resource 'per-interface network I/O counters' with detailed fields (bytes, packets, errors, drops). Clearly distinguishes from sibling tool get_network_connections which handles sockets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('bandwidth and drop analysis') and names the alternative (get_network_connections for sockets). This gives clear guidance on selecting between the two network-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and succeeds. It discloses read-only but heavy behavior, walks /proc and reads smaps for every process, ignores per-process errors, and fails only when the process list cannot be read. This is rich, honest behavioral information with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, cost warning, error behavior, and alternative guidance. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return details need not be in the description. The description covers purpose, sort and limit options, performance impact, failure semantics, and a sibling alternative, making it complete for this tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents limit and sort_by defaults and allowed values. The description restates the defaults and adds the rationale to keep the limit low, but it does not add substantial new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Returns running processes sortable by CPU, memory, or both,' using a specific verb and resource. It clearly differentiates from the sibling get_top_io_processes by directing disk I/O ranking to that tool, so the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Prefer get_top_io_processes for disk I/O ranking,' giving a direct alternative. It also advises 'keep limit low' due to heavy reading, indicating how to use the tool safely and when to consider a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares the operation is read-only, warns it is heavy and scans the filesystem, and notes root is required to see everything. This covers safety, performance, and privilege expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and wastes no words. Each sentence adds distinct value: what it does, behavioral caveats, and when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and the presence of an output schema, the description is complete: it explains the tool's scope, scoring, operational weight, and privilege requirements. No additional return-format explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially satisfied. The description still adds useful context about what the audit covers, which enriches the meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Runs a security audit') and enumerates concrete checks (firewall rules, SSH hardening, SUID binaries, etc.), plus a 0-100 score. This clearly distinguishes it from diagnostic siblings like get_audit_logs or get_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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Use for hardening reviews, ideally during low load.' It does not explicitly name excluded alternatives or when-not-to-use, but the context is strong enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/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 read-only via systemctl status, explains how errors are surfaced (errors field with raw output), and clarifies that only a missing systemctl is fatal. This is rich behavioral context beyond what annotations might provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Every sentence adds distinct value: purpose, validation, read-only nature, error behavior, and usage guidance. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description is complete. It covers purpose, usage, error handling, and alternatives. Since an output schema exists, return-value details are not needed. The description fully equips 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (name and user). The description adds minimal semantic value beyond restating that name is required and mentioning --user, which is already covered by the schema. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns detailed status of a systemd service' with a specific verb and resource. It also distinguishes itself from the sibling tool get_systemd_units by noting that get_systemd_units is for listing states, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a use case ('Use to check why a service failed') and names an alternative ('get_systemd_units to list states'). This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden: it discloses requirements (smartctl, root), per-device failure behavior (status unknown), and the only fatal condition (missing smartctl). This is excellent behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy: first states the purpose, second covers parameter behavior, third covers prerequisites and error handling. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 1-optional-param tool with an output schema, the description covers prerequisites, error semantics, parameter handling, and performance characteristics, making it fully complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the device parameter, but the description adds the performance implication of scanning all devices ('slow with many disks'), which goes beyond the schema and provides valuable usage nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns SMART disk health with specific attributes (status, temperature, power-on hours) via smartctl, distinguishing it from sibling tools like get_disk_info or get_block_devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is given: device is optional, empty probes all devices with a performance warning. It does not explicitly name alternatives, so while the usage context is solid, it lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses read-only nature, aggregate behavior, and that sub-failures land in errors field and are never fatal, giving useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verdict and sources, followed by usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only health check with an output schema, the description covers what it does, when to use it, and its non-fatal error behavior. Sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds no parameter details but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Returns' with clear resource: an overall OK/WARNING/CRITICAL verdict derived from memory, disk, load, and systemd units. Distinguishes itself from sibling get_system_snapshot by positioning as first-line health check vs full detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use as the first-line health check' and points to get_system_snapshot for full detail, providing both when-to-use and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 the read-only nature ('Read-only (gopsutil host.Info plus sysfs)') and the failure condition ('Fails only if host info is unavailable'). This adds meaningful behavioral context beyond schema and annotations, though it could detail error output or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) and front-loaded with the functional result list, followed by usage guidance. Every sentence adds value with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, output schema exists), the description covers all necessary aspects: what is returned, the read-only safety profile, the failure condition, and the intended use case. It names the alternative for health verdicts, making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4 per the rubric. The description does not need to explain parameters, and the empty schema confirms no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns host info with a specific list of fields (hostname, OS, kernel, etc.). It distinguishes itself from siblings by positioning it as a single-machine identity summary, contrasting with get_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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use for a single-machine identity summary; for a health verdict use get_system_health_check.' This names an alternative and specifies the intended context, satisfying the when-to-use vs alternatives criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 and does so excellently. It discloses that the tool is read-only (via timedatectl and chronyc), and that failures are non-fatal with an 'errors' field, giving the agent important behavioral expectations without needing to invoke the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the core purpose, return contents, implementation mechanism, error handling, and intended usage. No wasted words, and the main function is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool, the description is complete. It lists return fields (including the 'errors' field), explains the tools used, and gives a use case. The presence of an output schema further reduces the need to describe return values in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema fully covers the parameter aspect. The description adds no parameter details, but that is not needed; per the rubric, the baseline for 0 params is 4. It correctly focuses on outputs and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('NTP/Chrony sync state'), listing distinct data items (service, sync status, times, stratum, offset). This clearly differentiates it from sibling 'get_*' tools, none of which focus on time synchronization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the use case ('Use for clock-drift diagnosis'), providing clear context. However, it does not mention alternatives or when not to use, as there are no close sibling tools for time sync, so no exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/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 read-only nature, the sampling interval, and the error handling when pidstat is unavailable (error in the 'errors' field with empty results). This is thorough for a simple read-only 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each providing distinct value: the primary action, the safety/error behavior, and the usage guidance versus an alternative. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single optional parameter and an output schema, the description covers purpose, usage context, and error behavior. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'limit', is fully described in the schema with default and max values. The description does not add additional semantic context for the parameter beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns processes with the highest disk I/O activity, specifying the exact command (pidstat -d 1 1) and sampling duration. It also distinguishes itself from the sibling tool get_disk_io_metrics by noting that the latter provides per-device totals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool ('Use to find which process is hammering the disk') and names the alternative ('get_disk_io_metrics for per-device totals'). Also covers a failure mode (pidstat missing) and resulting behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 the tool is 'Read-only' and reveals how failures are handled (errors field for missing crontab). This gives reasonable transparency for a simple read-only aggregator, though it doesn't discuss edge cases like partial failures or permissions. Given the lack of annotations, this is strong 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the tool's scope and components, the second adds safety and error-handling info plus usage guidance. Every sentence adds value with no redundancy or padding, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters) and the presence of an output schema, the description covers the essential points: what it aggregates, that it's read-only, error handling, and usage context. It distinguishes from the most relevant sibling. There's no need to describe return values since an output schema exists, so the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is an empty object with 100% coverage. Per the rubric, an empty-parameter tool gets a baseline of 4. The description appropriately doesn't add parameter details because none exist, so no points deducted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('aggregates') and resource ('current user's scheduled tasks'), enumerating the exact sources (crontab -l and systemd user timers). It also explicitly differentiates itself from the sibling tool get_cron_jobs by specifying scope (user-level vs system-wide).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use for user-level automation') and directly names the alternative for system-wide cron ('get_cron_jobs for system-wide cron'). This is a clear, actionable usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses key behavioral traits: it is blocking up to timeout seconds, read-only, returns partial results in the errors field on failed pings, and is fatal only for invalid hosts. This is substantial transparency for a network tool, though it does not detail exact return structure beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the core function first, then parameters, then behavioral traits and usage guidance. Every sentence adds value, and there is no冗余 repetition of schema details. Ideal length for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations, the description covers purpose, parameter defaults, blocking behavior, error handling, and recommended use case. An output schema exists, so return values are already structurally defined. This is a complete and self-sufficient description for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the schema carries the parameter definitions. The description adds meaningful behavioral context: host is required and validated, count defaults to 4, timeout defaults to 10s, and behavior on failure is partial results. This goes beyond the schema baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends ICMP packets and returns latency, packet loss, and response times. It distinguishes itself from sibling tools like resolve_dns by explicitly noting its use for reachability checks, making its purpose 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use for reachability checks; resolve_dns to separate DNS from connectivity.' This directly tells the agent when to use this tool versus an alternative, fulfilling the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 and does so well: it states the tool is read-only, does not refresh cache, may be fatal on unsupported package managers, and handles a pacman error with empty output by returning an empty list. This is thorough and builds accurate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and every sentence adds value: operation, behavior, and usage guidance. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description covers when to use it, what it does, its limitations, and error behavior. Since an output schema exists, return value details are not needed. The description is complete and well-scoped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage), so the baseline is 4. The description adds no parameter-specific semantics because there are none, but it does mention the underlying commands, which provides useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Counts or lists available package updates without applying them' and even gives the underlying commands (pacman -Qu or apt list --upgradable). It also distinguishes itself from the sibling get_installed_packages by noting it handles pending updates rather than current versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to see pending updates; get_installed_packages for current versions,' providing a clear usage context and naming an alternative tool. It also notes the tool does not apply updates or refresh cache, which helps avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 reveals that the operation is read-only ('Read-only from sysfs and /proc/mounts'), excludes certain device types, and that errors are placed in an 'errors' field. This is rich behavioral context beyond what any structured field could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence states the primary purpose, the second covers behavioral constraints, and the third provides usage guidance. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with no parameters and an output schema. It covers read-only behavior, skipped device types, error handling, and usage compared to a sibling tool. The output schema handles return value details, so the description need not repeat them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is trivially 100%. The description adds no parameter-specific details, but none are needed. The baseline score of 4 for 0-parameter tools is appropriate, and the description does not detract from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns block devices and partitions: names, sizes, filesystem types, and mount points.' This is a specific verb+resource definition that distinguishes it from siblings like get_disk_info, which is explicitly noted as handling usage percent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: 'Use for storage inventory; get_disk_info for usage percent.' This names the alternative tool and gives a clear directive on when to use this tool vs. the alternative. It also implies when not to rely on it by noting loop, ram, and zram devices are skipped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses read-only nature and the failure condition ('fatal only if systemd-analyze is missing or fails'), plus output composition. This is strong behavioral transparency for a simple read command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary function and result, then adds a usage pointer. Every sentence earns its place with no verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description covers what is returned, ordering, read-only property, failure behavior, and provides a sibling alternative. This is fully complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter-level semantics are not applicable. The baseline for 0-parameter tools is 4, and the description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns systemd units ordered by init time from systemd-analyze blame, with unit names and durations. It distinguishes itself from the sibling get_boot_critical_chain by directly acknowledging and pointing to it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to find slow-starting services' and directs users to get_boot_critical_chain for the dependency chain. This provides clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: it is read-only, requires no root, and missing paths land in the errors field. This goes beyond the basics and provides actionable safety and error-handling information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the main purpose, followed by safety and usage guidance. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 is complete. It covers what is returned, error behavior, and usage context, making it sufficient 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any. Baseline for zero parameters is 4, and the description adds value by explaining what the tool returns and how missing paths are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns system-level cron jobs from specific locations (/etc/crontab and periodic directories), using a specific verb and resource. It also distinguishes itself from get_user_automation, which is its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this for system automation and points to get_user_automation for user-level tasks. It also notes that it is read-only and requires no root, providing clear context for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool reads from /proc/diskstats, skips loop/ram/zram devices, and is fatal only if unreadable. This is transparent about data source, filtering, and error behavior—excellent context beyond the basic read-only claim.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by behavioral details and usage guidance. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an output schema exists, and sibling tools provide contrast, the description is fully complete. It covers what the tool does, how it behaves, when to use it, and alternatives—enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 empty input schema is fully documented, and no parameter details are needed. The description concentrates on output semantics rather than parameter meaning, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('per-device disk I/O') with fields ('reads, writes, sectors, and timings'). It distinguishes from siblings by explicitly mentioning per-process I/O as a different tool (get_top_io_processes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use for storage performance; get_top_io_processes for per-process I/O.' This tells the agent when to invoke this tool and names the alternative for a different use case. The read-only and failure conditions also help clarify appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/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 read-only behavior, non-recursive scanning, how directory sizes are computed (own stat size, not contents), and that failures silently return empty results. These are important behavioral characteristics beyond a simple 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the main action in the first and limitations/alternatives in the second. No redundant fluff; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return format need not be described. The description covers purpose, scope, limitations, failure behavior, and alternatives, making it fully complete for a simple two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving baseline 3. The description adds semantic value by clarifying the directory-size interpretation and the limit bounds (10-100), reinforcing schema details. However, the additional parameter insight is modest, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the top N largest entries in a directory by size, with default path and limit details. The verb 'Lists' and resource 'top N largest entries' make the function explicit, and it distinguishes from get_disk_info by stating it is for quick space triage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: 'Use for quick space triage; get_disk_info for partition-level capacity.' It also states limitations (non-recursive, single directory level) to set expectations, making it clear when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses that the tool is read-only via systemctl, which is a safe operation, and that it is fatal if systemctl is missing or fails. This gives crucial behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, then parameter details, then usage guidance. Every sentence earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema. The description covers purpose, usage, behavioral traits, and parameter semantics comprehensively, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the state parameter with full coverage, but the description adds meaning by specifying that it filters by exact match on the Active column, clarifying the matching semantics beyond the schema's simple listing of allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all systemd units and their states, with a specific verb and resource. It also distinguishes itself from get_service_status for one unit's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is for a full service inventory and directs to get_service_status for single-unit details. It also explains the state parameter filters by exact match, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 and does so admirably. It explicitly states 'Read-only', discloses that individual gather failures fall back to zero values in the errors field and are 'never fatal', and warns about the performance weight. These behavioral traits are not visible elsewhere and are valuable for an agent deciding to invoke this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences and every sentence serves a distinct purpose: what it returns, read-only nature, failure fallback behavior, and usage guidance. It is front-loaded with the core purpose and maintains high information density without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a zero-parameter tool with an output schema. It covers the composition of the snapshot, error behavior, and usage context. It also successfully differentiates itself from the highly similar sibling get_docker_system_snapshot by including both system and Docker data. The output schema likely details the return structure, so no further field listing is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to describe. Per the rubric, 0 params earns a baseline 4. The description correctly implies no input is needed, and the empty schema with 100% coverage confirms this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'comprehensive snapshot' and enumerates the included data categories (system, CPU, temperature, memory, disk, network, load, top processes, Docker). It distinguishes itself from target-specific siblings by emphasizing 'in one call' and positioning it as a 'broad overview' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use for a broad overview; prefer targeted tools for deep questions.' It also warns that this is 'the heaviest call in the server,' informing the agent about performance trade-offs. This gives clear when-to-use and when-not-to-use direction relative to the many sibling get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Mohabdo21/linux-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server