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

Beyond the readOnly/idempotent annotations, the description discloses the actual mechanism (TCP connect with a timeout), the possible outcomes (open, closed/refused, timed out, DNS failure), and that latency is included when open. This gives the agent an accurate mental model of tool behavior without needing to call it speculatively.

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

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

The description is compact and front-loaded: purpose first, then mechanism/use case, then return format. Every sentence contributes useful information without redundancy. The return contract is clearly specified in a structured way.

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

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

Given the simple three-parameter schema, rich annotations, and output-schema signal, the description covers everything an agent needs: what it does, how it behaves, and what it returns. No critical gap remains, and the tool is simple enough that additional detail would be noise.

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

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

Schema description coverage is 100%, and every parameter (host, port, timeout_seconds) is already well documented with defaults, ranges, and examples. The tool description mentions a timeout generally but adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Test whether a TCP port is accepting connections.' It clearly distinguishes this tool from the sibling system-monitoring tools (CPU, memory, disk, processes) by focusing on network reachability of a specific port. The example 'is Postgres up on 5432?' makes the purpose immediately concrete.

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

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

The description provides clear usage context: 'Useful for verifying a service is listening... before deeper diagnosis.' This tells an agent when to reach for the tool. It does not explicitly name alternatives or list when-not-to-use scenarios, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds valuable behavioral context beyond annotations: it samples for sample_seconds, reports load averages, and interprets load-per-core saturation. This meaningfully helps an agent understand what the tool actually does.

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

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

The description is front-loaded with the main purpose, followed by sampling behavior and a compact return-value breakdown. Every sentence adds useful information, and the structured Returns block makes the output contract easy to parse without unnecessary verbosity.

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

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

For a read-only diagnostic tool with three optional parameters, annotations, and a documented return format, this description is complete. It states the output types, the keys returned, the optional per-core detail, and the saturation threshold. An agent has enough information to select and invoke the tool correctly without further inference.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining sample_seconds behavior and the load-per-core saturation threshold. It also clarifies the optional per_core_percent output, connecting the per_core parameter to its effect.

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

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

The description opens with a specific verb and resource: 'Get CPU utilization, core counts, and load averages.' This clearly differentiates it from sibling tools like get_memory_status and get_disk_usage. The return format section further confirms exactly what data the tool produces.

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

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

The description implies usage for CPU-focused monitoring but never explicitly says when to choose it over alternatives or when not to use it. It provides helpful interpretation guidance like 'values >= 1.0 indicate saturation,' but no direct comparison to sibling tools or exclusions.

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

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

Annotations already declare a safe, read-only, idempotent profile. The description adds meaningful behavioral detail: read-only mounts are listed but never flagged, and snap squashfs mounts are 100% by design. This is exactly the kind of non-obvious behavior an agent needs.

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

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

The description is compact, front-loaded with the core purpose, and every sentence adds value. The edge-case explanation and return structure are included without unnecessary bulk.

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

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

The description covers purpose, optional path behavior, the warning threshold, read-only edge cases, and the exact return shape. An agent has everything needed 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.

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

Schema description coverage is 100%, so the parameters are already fully documented. The description reinforces the warning threshold and output formats but does not add significant meaning beyond the schema, 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.

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

The description uses a specific verb-resource pairing ('Get disk usage per partition') and adds a distinctive behavior (flagging above a warning threshold). This clearly separates it from sibling status tools like get_cpu_status and get_memory_status.

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

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

The context is clear: agents can infer this is the tool for partition capacity inspection, and the optional path parameter explains how to narrow scope. It does not explicitly name alternatives or exclusion cases, but no sibling tool competes for the same resource.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it aggregates key signals, produces a plain-language assessment, and explains the returned format and keys, which is exactly the kind of beyond-annotation disclosure that helps 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.

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

The description is efficient and well-structured: the core value is front-loaded, the usage guidance is in a short paragraph, and the Returns section is compact but informative. No sentence is wasted.

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

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

For a read-only tool with one optional parameter, the description fully covers what it does, when to use it, what the output looks like, and how it relates to sibling tools. The annotations cover safety, and the schema covers the parameter, so nothing essential is missing.

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

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

Schema coverage is 100% and the schema already documents response_format with an enum and description. The description adds value by tying the parameter to concrete outputs: 'Markdown summary or JSON object with keys: hostname, boot_time, uptime_hours, ...' which clarifies what the caller will receive.

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

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

The description opens with a clear verb and resource: 'One-call health snapshot' listing the exact signals (hostname, uptime, CPU, RAM, swap, fullest disk). It also distinguishes itself from siblings by framing itself as the aggregated first tool, so an agent can tell it apart from get_cpu_status, get_memory_status, etc.

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

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

The description explicitly says it is 'the right first tool to call when asked how is this box doing?' and instructs that follow-up tools should only be called 'where something looks off.' This provides clear when-to-use guidance and implicitly names the alternative follow-up tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral detail beyond annotations by specifying the two possible return formats (markdown vs. JSON) and the exact keys returned for virtual and swap memory. This helps the agent understand response handling.

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

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

The description is compact and front-loaded with the core action, followed by a structured Returns section. Every sentence earns its place, and there is no redundant wording or filler.

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

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

For a simple read-only tool with one optional parameter, the description is complete. Annotations cover safety, the schema covers the parameter, and the Returns section covers output structure. The agent has enough information 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.

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

Schema description coverage is 100%, and the schema already fully documents the single optional response_format parameter, including its enum values and default. The description adds no new parameter-level meaning beyond what the schema provides, so 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.

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

The description states a specific verb and resource: "Get RAM and swap utilization." This clearly distinguishes it from sibling tools like get_cpu_status, get_disk_usage, and get_network_status, which cover different system resources. The additional return-format detail reinforces what the tool produces.

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

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

The description implies use when memory status is needed, but it gives no explicit guidance about when to choose this tool over alternatives or when not to use it. There are no stated exclusions or preferences relative to the sibling tools, so usage context is only inferred from the resource named.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds behavioral details beyond that, such as returning either Markdown or JSON, reporting I/O totals 'since boot', and conditionally including TCP state counts, which helps the agent understand what the tool actually produces and what optional behavior is available.

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

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

The description is well-organized: the primary function is stated first, followed by the optional feature and its use case, then a compact return-format summary. Every sentence contributes useful information, and there is no filler or repeated schema content.

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

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

This is a simple read-only tool with only two optional parameters, and the description covers the tool's scope, optional behavior, and return structure. The output format is fully described with specific keys, so an agent has enough information to invoke it correctly without additional context.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value for include_connections by explaining its diagnostic purpose ('spotting connection leaks or unexpected listeners'), which goes beyond the schema's simple field description. It also clarifies the structure of the return object, aiding parameter interpretation.

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

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

The description opens with a specific verb and resource: 'Get network interfaces, their addresses, and I/O totals since boot.' It clearly defines the tool's scope and differentiates it from sibling status tools like get_cpu_status or get_memory_status by focusing on network-specific data.

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

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

The description gives clear context for using the optional include_connections feature, noting it is 'useful for spotting connection leaks or unexpected listeners.' It does not explicitly name alternatives or exclusions, but the network-focused purpose is evident from the first sentence, which is sufficient given the sibling tool names.

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

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

Annotations already declare readOnlyHint and destructiveHint, covering safety. The description adds useful behavioral context by specifying the return format options and the exact keys and process fields returned. This goes beyond the annotations without contradicting them.

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

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

The description is compact and front-loads the core purpose in the first sentence. The Returns block is concise and directly useful, with no redundant phrasing or unnecessary details.

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

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

For a read-only, list-style tool with full parameter schema and an output schema, the description provides enough context to call the tool correctly. It could be slightly stronger by explicitly stating when to prefer it over sibling status tools, but nothing critical is missing.

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

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

Schema description coverage is 100%, and every parameter already has a clear description. The tool description does not add substantial parameter-level semantics beyond restating the sorting dimension and return structure, 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.

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

The description clearly states the tool returns the top processes sorted by CPU or memory consumption, using a specific verb and resource. It is clearly distinct from sibling tools like get_cpu_status or get_memory_status, which focus on system-level metrics rather than process-level rankings.

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

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

The description implies when to use the tool—when process-level CPU or memory ranking is needed—but does not explicitly contrast it with alternatives like get_cpu_status or get_memory_status. It offers no exclusion criteria or when-not-to-use guidance, leaving some selection reasoning to the agent.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful behavioral constraints: reads are restricted to allowed log roots, limited to 500 lines, and symlinks are resolved before path checks. It also explicitly states the return type as matching lines or an actionable error message. This gives the agent concrete expectations about side effects, security boundaries, and failure behavior.

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

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

The description is compact, front-loaded with the primary purpose, and uses short paragraphs for safety and return details. Every sentence adds useful information without redundancy, and the Returns section is clearly separated. There is no filler or unnecessary elaboration.

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

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

Given the tool's moderate complexity, rich input schema, read-only annotations, and clear sibling separation, the description fully covers what an agent needs to invoke it safely and interpret its output. It explains the safety boundary, symlink handling, line limit, filtering behavior, and return format. Nothing essential is missing.

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

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

Schema description coverage is 100%, with path, grep, and lines all documented in the input schema. The description adds some context about the 500-line cap and allowed roots, but these mostly mirror the schema's constraints. It does not materially enrich parameter meaning 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.

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

The description opens with a specific verb and resource: 'Read the last N lines of a log file, optionally filtered by substring.' This clearly distinguishes tail_log from its system-monitoring siblings, which report CPU, memory, disk, processes, network, ports, and host summary. The scope and behavior are immediately unmistakable.

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

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

The description makes the main use case obvious: reading recent log content with an optional substring filter. While it does not explicitly name alternative tools or state when not to use it, the sibling context makes the differentiation clear, and the safety constraints provide implicit guidance on valid usage. No exclusionary or misleading usage cues are present.

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