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

Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds nothing beyond that — it does not mention that the host may be reached over SSH, nor anything about permissions or scope of the read.

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?

It is short, but this is under-specification rather than conciseness. The single sentence duplicates the title and earns no informational place.

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?

An output schema exists, so return values need not be described. However, for a tool with numerous similar siblings and a remote-SSH capability, the description should at least distinguish it from get_hardware_information and get_system_information, which it does not.

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 single 'host' parameter is fully documented in the schema, including the localhost-vs-SSH distinction and examples. Per the baseline rule for high coverage, the schema carries the burden and a 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 is a verbatim restatement of the tool name and title ('Get CPU information'), making it a tautology. It does not distinguish this tool from siblings such as get_hardware_information or get_system_information, which plausibly also surface CPU 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?

There is no guidance on when to use this tool versus the many overlapping siblings (get_hardware_information, get_system_information, get_memory_information). No conditions, prerequisites, or exclusions are stated.

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?

The readOnlyHint annotation already declares this is a safe read operation. The description adds what information is returned (size, mount points, utilization), which is useful context. It doesn't elaborate on remote SSH behavior or potential timeouts, but with annotations covering safety profile, a 3 is appropriate.

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

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

A single, well-formed sentence that is front-loaded with the main purpose and efficiently lists the returned details. No wasted words.

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 presence of an output schema (which likely details return values) and a 100% coverage schema for parameters, the description is nearly complete for an agent to understand the tool's purpose and invocation. It could benefit from a note on remote host handling or timeouts, but those are minor given the structured fields.

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 single parameter 'host' is fully documented in the schema, including examples and the distinction between localhost and remote SSH. The description adds no parameter details beyond what the schema provides. Baseline 3 is correct when schema does the heavy lifting.

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?

States a specific verb ('Get') and resource ('disk space information') with the fields returned (size, mount points, utilization). It is clearly distinguishable from siblings like get_memory_information or get_cpu_information, though it doesn't explicitly call out that differentiation.

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?

Usage is implied by the tool's purpose (retrieving disk space info), but there is no explicit guidance on when to use this vs alternatives, nor any mention of prerequisites or exclusions. Adequate but with a clear gap.

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?

readOnlyHint=true already signals a safe read, and the description usefully enumerates the hardware data sources it surfaces. Beyond that it adds nothing behavioral — no note that the host may be reached over SSH, no indication of cost or latency for remote probes, and no hint about breadth of the payload.

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?

One compact sentence with the verb and resource front-loaded and zero filler. It is arguably too terse for the scope of data covered rather than too long, but nothing 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?

An output schema exists, so return values need no prose explanation, and the read-only annotation covers the safety profile for a one-parameter tool. The remaining gap is sibling differentiation — an agent cannot tell from this text when to prefer it over get_cpu_information or get_system_information.

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?

There is a single parameter with 100% schema description coverage, and the schema itself already explains the 'localhost vs remote host over SSH' semantics. The description adds no additional parameter meaning, so this sits at the baseline for full schema coverage.

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?

States a specific verb ('Get') and resource ('hardware information') and enumerates the sub-domains (CPU, PCI, USB, DMI), so the agent knows what will be returned. However, it never distinguishes itself from overlapping siblings like get_cpu_information or get_system_information, leaving the agent to guess at the boundary.

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 no when-to-use guidance, no prerequisites, and never names an alternative even though get_cpu_information and get_system_information plausibly overlap with it. The agent receives no routing information at all.

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?

The readOnlyHint annotation already declares this a safe read, so the safety profile is covered. The description adds nothing beyond it: no note that 'host' may trigger SSH to a remote system, no mention of permissions, and no behavioral context. It simply restates the resource.

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?

A single short sentence with zero filler, front-loaded and readable. It is efficient, though arguably under-specified rather than optimally concise given the tool's 7-parameter complexity.

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?

An output schema exists, so return values need not be explained, and the schema is fully documented. But for a filtering-heavy tool with a remote-SSH host parameter and multiple overlapping log siblings, the description leaves routing and context gaps that a richer definition should fill.

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 schema fully documents all 7 parameters including examples, defaults, and the mutual exclusivity of last_lines/first_lines. The description contributes no additional parameter meaning, so the baseline 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?

States a specific verb and resource: 'Get systemd journal logs.' This is clearer than a tautology and identifies the data source precisely. However, it offers no differentiation from siblings like get_service_logs or read_log_file, which also retrieve logs, so an agent cannot tell them apart from the description alone.

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 no when-to-use guidance, no conditions, and no mention of alternatives. With siblings get_service_logs and read_log_file present, some routing hint would be valuable but is entirely absent.

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?

The readOnlyHint annotation already declares this a safe, non-destructive read, and the description does not contradict it. The description adds only a light statement of returned content (protocols, services) and says nothing about remote-host auth, timeouts, or privilege requirements, which is acceptable given annotation coverage but not rich.

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?

A single tight sentence with the action and the returned content front-loaded and zero filler. Nothing could be trimmed without losing information.

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?

With an output schema covering return values, a fully documented parameter, and a readOnly annotation covering safety, the description is nearly sufficient to call the tool correctly. The only missing piece is guidance on when to prefer it over sibling network tools.

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%: the single 'host' parameter is fully documented, including the 'localhost' vs remote-SSH semantics. The description adds nothing beyond that, so the baseline 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?

States a specific verb ('Get') and resource ('listening ports') plus the returned facets (protocols, services), so an agent knows exactly what data comes back. It does not, however, distinguish itself from the closely related sibling get_network_connections, which an agent must open a schema to disambiguate.

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?

There is no when-to-use guidance, no mention of alternatives like get_network_connections, and no stated prerequisites (e.g., SSH access for remote hosts). The agent must infer all invocation context from the schema alone.

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?

readOnlyHint=true already establishes this as a safe read, and the description adds that the result covers both physical and swap memory, which is useful scope information. However, it says nothing about behavior for remote hosts over SSH, latency, or failure modes when a host is unreachable, so it adds only modest context beyond the annotations.

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?

A single front-loaded sentence with zero filler, covering verb, resource, and content scope. It is efficient, though extremely terse given it is the entire description.

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?

With an output schema present, the description need not explain return values, and the sole parameter is fully documented in the schema. What remains missing is only usage/alternative guidance, which is a minor gap for a simple read tool.

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 host parameter is fully documented in the schema (localhost vs remote SSH host). The description adds no parameter-level meaning, 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?

States a specific verb+resource ('Get detailed memory') and scopes the content to physical and swap memory, which cleanly separates it from siblings like get_cpu_information and get_disk_usage. It does not name a sibling or explicitly rule out alternatives, but the resource is unambiguous.

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?

There is no explicit when-to-use guidance, no mention of when to prefer get_system_information or other resource tools, and no prerequisites stated. Usage is only implied by the tool name and the memory resource it targets.

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?

The readOnlyHint=true annotation already establishes this is a safe read, lowering the bar. The description contributes the scope qualifier 'active' (implying established connections rather than listening sockets), but says nothing about remote SSH execution behavior or result volume.

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?

A single front-loaded sentence with no filler. It is efficient, though arguably too terse to carry any routing or scoping guidance.

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?

An output schema exists, so return values need not be explained, and the single parameter is well covered. What is missing is any differentiation from the many sibling system-inspection tools, leaving the agent to infer routing on its own.

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%: the 'host' parameter is fully documented in the schema, including the localhost-vs-SSH semantics and examples. The description adds nothing about the parameter, so the baseline 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?

States a specific verb and resource ('Get ... active network connections'), so the agent knows this returns connection data. However, it does not differentiate from siblings such as get_listening_ports or get_network_interfaces, which an agent could easily confuse with 'connections'.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The description gives no signal about when to pick this over get_listening_ports or get_network_interfaces.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description's burden is light. It adds useful content context (address and traffic statistics), but says nothing about SSH auth requirements for the remote-host path or whether the call can be slow or partial on unreachable hosts.

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?

One tight sentence that leads with the action and immediately names the returned data. Nothing redundant or padded.

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?

With an output schema present, return-value detail need not be in the description, and the single parameter is fully documented. For a simple read-only tool this is nearly sufficient; only the remote-host connection behavior is left unstated.

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?

There is a single 'host' parameter and the schema documents it at 100% coverage, including the localhost-vs-SSH semantics and examples. The description adds nothing 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?

States a specific verb (get) and resource (network interfaces) and names the payload (addresses, traffic statistics), so the agent knows exactly what comes back. It does not explicitly contrast itself with the adjacent siblings get_network_connections and get_listening_ports, so the distinction must be inferred from the resource name.

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 no when-to-use context, no prerequisites, and does not mention the closely related get_network_connections or get_listening_ports siblings an agent could confuse it with. Usage is only implied by the resource name.

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?

readOnlyHint=true already declares this is a safe read, and the description adds no behavioral context beyond that. It doesn't mention SSH connectivity behavior implied by the 'host' param, failure modes for an unknown pid, or permissions. With annotations covering the safety profile, this is an acceptable but thin baseline.

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?

A single efficient sentence with the purpose front-loaded and no waste. It is arguably under-specified rather than verbose, but it does not pad or bury the key information.

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?

An output schema exists, so return values need no explanation, and annotations cover safety. For a two-param read tool this is minimally sufficient, but the lack of any sibling routing or host/SSH behavior note leaves the definition adequate rather than complete.

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 descriptions are rich (pid examples, host semantics including localhost vs SSH remote). The description contributes nothing beyond the schema, so baseline 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?

States a clear verb+resource: "Get information about a specific process." The word 'specific' implicitly distinguishes it from list_processes and get_system_information, but it never names or contrasts with a sibling. Clear purpose, no explicit differentiation.

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?

No guidance on when to use this versus list_processes (bulk) or get_system_information (host-level). No prerequisites or alternatives are mentioned. The agent must infer routing from the name alone.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description only adds the word 'recent'; it says nothing about whether it reads via journald, whether elevated privileges or SSH keys are needed on remote hosts, or any truncation/rate behavior, so it adds almost no context beyond the annotation.

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

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

A single front-loaded sentence with no filler. Nothing is redundant and the key resource qualifier ('systemd service') comes immediately.

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?

With an output schema present and 100% param coverage, return values and parameters need no description space. However, for a log-retrieval tool sitting next to get_journal_logs and read_log_file, the total absence of routing guidance leaves a meaningful completeness gap.

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 host, service_name, and lines are fully documented in the schema (including SSH semantics and line limits). The description adds no parameter meaning beyond that, so the baseline 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?

States a specific verb and resource: getting recent logs for a specific systemd service. Clear enough to distinguish from generic file readers, but it never names or rules out overlapping siblings such as get_journal_logs, which can also return per-unit service output.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives. An agent facing get_journal_logs, read_log_file, and this tool gets no signal about which to pick for service log output.

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?

readOnlyHint=true is consistent with 'Get detailed status', so no contradiction. Beyond that the description adds nothing behavioral (no output format, no permissions, no remote-SSH caveats), but with annotations covering the safety profile and an output schema covering returns, a baseline 3 is fair.

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?

A single front-loaded sentence with no filler; every word (verb, scope, resource) earns its place.

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 lookup with a complete two-parameter schema and an output schema, the description is sufficient. It is slightly thin on how it relates to sibling status/log tools, but nothing essential to correct invocation 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 both parameters (host, service_name) are fully documented with examples, so the schema carries parameter semantics. The description adds no format or syntax detail, matching the baseline 3 for high-coverage schemas.

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?

States a specific verb ('Get') and resource ('detailed status of a specific systemd service'), so an agent knows it retrieves state for one named service. It does not explicitly differentiate itself from siblings like list_services or get_service_logs, keeping it below a 5.

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 word 'specific' implies single-service lookup versus a list, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. list_services for enumeration, get_service_logs for logs). Usage is only implied.

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?

The readOnlyHint annotation already establishes this is a safe, non-mutating call, so the bar is lower. The description does add genuine context by disclosing that PCP installation/service status and historical PCP time ranges are included, which the schema does not reveal. However, it says nothing about SSH connection behavior for remote hosts, latency, or permissions, so it is solid but not rich.

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?

A single sentence that front-loads the core purpose ('Get basic system information') and then lists specifics. Every enumerated item is meaningful content, with no filler or redundancy.

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?

An output schema exists, so the description is not obligated to explain return values, and it is complete enough for an agent to call the tool correctly. The only mild gap is the absence of guidance on remote/SSH prerequisites and how this differs from the other system-information siblings.

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?

There is a single parameter ('host') and schema description coverage is 100%, with the schema itself explaining 'localhost' vs a remote host over SSH and providing examples. The description adds no parameter-level meaning beyond that, 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 gives a specific verb ('Get') plus a resource ('basic system information') and then enumerates the exact contents: OS, distribution, kernel version, uptime, last boot time, PCP install/service status, and historical PCP time ranges. This enumeration implicitly distinguishes it from narrower siblings like get_cpu_information and get_hardware_information, but it never names an alternative explicitly, so it falls short of a 5.

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?

There is no explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative. Usage is only implied by the enumerated contents — an agent can infer it is the general system-overview tool versus the specialized per-resource tools, but must make that inference itself.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, and an output schema exists to describe the result. The description adds nothing beyond that — no detail on remote-vs-local behavior (the host parameter allows SSH), no notes on what constitutes a block device, and no scoping caveats.

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?

One short, front-loaded sentence with no filler or redundancy. It is appropriately sized, though the terseness leaves little room for the routing detail an agent would benefit from.

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 low-complexity, single-parameter read tool with annotations and an output schema, the description is adequate but minimal. It omits any differentiation from storage-related siblings like get_disk_usage, which is the main gap for an agent choosing between them.

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 single host parameter is already fully documented in the schema, including the localhost/SSH distinction. Baseline 3 applies since the description adds no parameter semantics of its own.

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+resource ("List block devices") with a scope qualifier ("on the system"), so an agent knows exactly what it returns. It does not, however, distinguish itself from close siblings like get_disk_usage or get_hardware_information, which could also surface storage hardware.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as get_disk_usage. The agent must infer the correct context from the tool name alone.

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?

The readOnlyHint annotation already covers the safety profile, so the bar is lower, but the description still adds nothing: it does not say whether listing is shallow or recursive, whether hidden directories are included, or that it may execute over SSH on a remote host (the schema hints at this via 'host'). For a filesystem-facing tool this is a meaningful omission.

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?

One sentence, front-loaded with the verb and resource, with no filler. It is efficient, though arguably too terse for a five-parameter tool that can operate against remote hosts.

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?

An output schema exists, so return values need not be described. Still, for a tool that can target localhost or a remote host over SSH, the description leaves behavioral questions (recursion, permissions, remote execution) unanswered; it is minimally adequate rather than complete.

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 enum values and defaults documented for sort, order_by, and top_n, so the baseline of 3 applies. The description's phrase 'various sorting options' adds no meaning beyond the schema and says nothing about the interaction between order_by and sort.

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?

States a clear verb ('List'), resource ('directories'), and scope ('under a specified path'), which is more than a tautology of the title. However, it never distinguishes itself from the sibling 'list_files', leaving an agent to guess which one returns directories versus files.

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?

There is no guidance on when to choose this tool over 'list_files', 'read_file', or the other listing siblings. 'with various sorting options' describes capability, not usage context, so an agent gets no routing help.

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, so the safety profile is covered. The description adds only 'with various sorting options', which merely restates schema content; it says nothing about SSH remote-host behavior, result limits, permission failures, or pagination.

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?

A single front-loaded sentence that names the verb and resource immediately. The trailing clause 'with various sorting options' is mildly redundant filler but costs little.

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?

An output schema exists so return values need not be described, and annotations plus 100% schema coverage carry most of the burden. However, for a tool requiring a host/SSH target and offering sort/limit behavior, the description leaves the agent without any routing or scoping 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 description coverage is 100%, so all five parameters (including host, sort, order_by, top_n) are already documented with examples and defaults. The description's mention of sorting options adds no syntax or constraint detail beyond the schema, so the baseline 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?

Clear verb+resource: 'List files under a specified path'. The word 'files' implicitly separates it from the sibling list_directories, though the description never names that sibling explicitly, so the differentiation is inferred rather than stated.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_directories or read_file. The only usage hint is the existence of sorting options, which is a capability statement rather than guidance.

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?

The readOnlyHint=true annotation already establishes the safety profile, so the description's job is to add context — and it adds none. It doesn't disclose scope (all processes vs. a subset), output volume, whether remote SSH failures are surfaced, or any rate/permission considerations.

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?

A single four-word phrase with zero waste and the resource front-loaded. It is appropriately terse, though the terseness is partly under-specification rather than deliberate economy.

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?

With an output schema present and full parameter coverage, the description needn't explain return values, so the essentials are technically covered. Still, for a tool that can target remote hosts, the absence of any scoping or behavioral note leaves it only minimally complete.

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 single 'host' parameter is fully documented in the schema including the localhost-vs-SSH distinction. The description adds nothing beyond the schema, so the baseline 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 states a specific verb and resource ('List running processes'), so an agent immediately knows the operation and target. However, it offers no differentiation from siblings like get_process_info or list_services, leaving the boundary between 'listing' and 'inspecting' processes unstated.

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?

There is no when-to-use guidance, no mention of when to prefer get_process_info instead, and no stated prerequisites (e.g., SSH reachability for remote hosts). The agent must infer all routing decisions from the name alone.

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?

Annotation readOnlyHint=true already tells the agent this is a safe read operation. The description adds no behavioral context beyond the annotation (e.g., whether it requires systemd, whether it filters system vs. user services, or return volume).

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?

A single, front-loaded sentence with zero waste. Every word earns its place.

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 list operation with annotations covering the safety profile and a complete schema, the description is adequate. Slight gap: no guidance on filtering or relationship to get_service_status.

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 single parameter host is fully documented in the schema. Description adds no parameter information, but with full coverage the baseline 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?

States a specific verb (List) and resource (systemd services) with clear scope ('all'). Distinguishable from sibling get_service_status which would return a single service's 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 description implies usage by naming the resource, but never states when to use this over get_service_status or what preconditions exist. No explicit alternatives or exclusions are provided.

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?

readOnlyHint=true is already declared, and the description is consistent with it ('Returns the guide'). It adds useful framing that this is reference/documentation content rather than live telemetry, but says nothing about size, latency, or whether the guide is static versus host-dependent (it does take a host param). With annotations covering safety, this is adequate but not rich.

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?

Two sentences, zero filler, and the core purpose is front-loaded before the usage instruction. Every clause earns its place.

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?

An output schema exists, so return-value details are unnecessary, and the description correctly frames what the tool yields. It is nearly complete for a simple one-param reference tool; only the relationship to pcp_list_metrics is left unaddressed.

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 single 'host' parameter is fully documented in the schema, including localhost vs remote-SSH semantics. The description adds no parameter-level meaning, 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?

Specific verb+resource: 'Returns the PCP metrics guide', further qualified as a catalog of metric names and how to read values returned by the other PCP tools. This clearly distinguishes it from siblings like pcp_list_metrics and pcp_query_metrics, which return data rather than documentation.

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?

Explicitly states when to use it ('Read it before investigating performance with PCP') and a behavioral rule ('take metric names from it rather than from memory'). It does not, however, address when to prefer pcp_list_metrics over the guide, which is the closest sibling and an obvious ambiguity.

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 only declare readOnlyHint=true; the description adds substantive behavior — large sub-namespaces collapse to a single summary line, only pmlogger-recorded metrics appear, and everything listed is safe to pass to pcp_query_metrics. It also discloses the environment prerequisite, which annotations cannot express.

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?

Front-loaded with the core action, then the collapse/drill-down mechanic, then the routing rationale and prerequisite. Every sentence carries distinct information with no redundancy.

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?

Covers action, iteration strategy, result contract ('everything listed can be passed to pcp_query_metrics'), alternative tool (pcp_guide) and precondition. With an output schema present and full parameter coverage, nothing an agent needs to call this correctly 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 documents both parameters thoroughly, so the baseline is 3. The description adds real value beyond the schema by explaining the iterative drill-down semantics of 'prefix' (omit to start at top level, re-call with a collapsed name to descend), which the schema only hints at.

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?

States a specific action (browse/list metrics in the PCP namespace under a prefix) and distinguishes itself from siblings by naming pcp_query_metrics as the consumer and pcp_guide as the curated shortcut. The collapsing behavior of large sub-namespaces is also stated outright, so the agent knows exactly what this returns.

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?

Explicit routing: 'reach for this when you need a subsystem the guide does not cover', plus a hard prerequisite ('Use only if get_system_information() indicates PCP is available'). It also tells the agent how to drill down (call again with the sub-namespace name as prefix), which covers the iterative usage pattern.

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, so the safety profile is covered. The description adds a genuine behavioral prerequisite (PCP must be available) and the live-vs-historical capability, but says nothing about cost, output volume, or failure modes for a tool that aggregates five subsystems.

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?

Three short sentences, each earning its place: what it produces, its two modes, and the hard precondition. Front-loaded with the capability and no 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?

An output schema exists, so return values need no explanation, and the PCP-availability gate plus live/historical modes cover the essential decision inputs. Slightly incomplete in that it doesn't say what happens when PCP is absent or how large the snapshot may be.

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 both host and timestamp are fully documented in the schema, including the timezone-handling nuance and the 'now' keyword. The description only mirrors the live-vs-past distinction already implied by the timestamp parameter, adding no new parameter detail; baseline 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?

States a concrete verb and resource ('condensed snapshot of CPU, memory, disk, network, and process information using pcp xsos'), which clearly distinguishes it from single-domain siblings like get_cpu_information or get_memory_information. It does not name the closer PCP siblings (pcp_query_metrics, pcp_list_metrics) as alternatives, so it stops short of a 5.

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?

Gives an explicit precondition: 'Use only if get_system_information() indicates PCP is available,' which is actionable gating the agent can check. It also clarifies the two usage modes (live system vs. a point in the past), but never names which sibling to use instead when the condition fails or when a narrower tool is preferable.

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?

With readOnlyHint=true already covering safety, the description still adds meaningful behavior: omitted start_time/end_time/interval produce defaults targeting one hour or ~20 samples, results come back as JSON samples, and an availability precondition gates the call. It stops short of covering remote-SSH auth requirements or 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?

Three tight sentences with zero filler; the core retrieval statement is front-loaded, followed by defaulting behavior and then the prerequisite/gating conditions. Every clause earns its place.

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?

An output schema exists, so return-format detail is unnecessary, and the description covers prerequisites, defaulting, and availability gating appropriately. Only minor gaps remain around remote-host connection/auth behavior, which matters given the 'localhost vs SSH' host parameter.

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, but the description adds real semantics beyond the schema: it explains the coordinated defaulting behavior across start_time, end_time, and interval, which the schema's 'default: null' entries do not convey.

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?

States a specific verb and resource ('Retrieves historical metric data from PCP archives as JSON samples'), and the word 'historical' distinguishes it from live/catalog siblings like pcp_list_metrics and pcp_performance_summary. It never names those siblings explicitly, so the disambiguation is inferential rather than stated.

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?

Explicitly prescribes the prerequisite chain: call pcp_guide first for the catalog and value semantics, never guess metric names, and only use this if get_system_information() reports PCP is available. That is when-to-use, when-not-to-use, and the alternative source, all 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?

readOnlyHint=true already establishes the safety profile, and the description adds one genuine behavioral fact: a size cap that can truncate content. However, it says nothing about how truncation is signalled, whether large files error or partially return, or what reading a remote host over SSH entails. Adequate but thin for a tool with a size-based failure mode.

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?

A single front-loaded sentence with no filler; the size constraint is stated immediately. It is efficient but so terse that it reads more like a label than a full specification.

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?

An output schema exists so return values need not be explained, and annotations cover the read-only nature. Still, a tool that reads either local or SSH-remote files under a size limit leaves gaps around truncation behavior and the local/remote distinction that the description could have closed in one sentence.

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 both 'host' (localhost vs. SSH remote) and 'path' (absolute) are fully documented in the schema. The description's only parameter-relevant contribution is the word 'text', implying binary paths are unsupported, which does not materially extend the schema. Baseline 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?

States a specific verb and resource ('Read the contents of a text file') plus a scope qualifier ('up to a safe size limit'). It is clear on its own, but does not differentiate from the sibling read_log_file, which overlaps heavily in purpose.

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?

No when-to-use guidance, no exclusions (e.g. binary files), and no routing to the obvious alternative read_log_file for log content. The reader must infer the choice purely from the 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?

readOnlyHint=true already tells the agent this is a safe read, so the description needn't restate safety. But it adds nothing beyond that: no mention of the allowed-list enforcement, no note that remote reads go over SSH, no disclosure of truncation/default line behavior. For a tool with a security-sensitive path constraint, this is thin.

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?

A single short sentence is certainly front-loaded and free of padding, but here brevity shades into under-specification rather than genuine conciseness. It is not wasteful, but it also does not earn its place by conveying anything the name and title do not already say.

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?

An output schema exists, so return values need not be explained, and the rich parameter schema covers inputs. What is missing is the surrounding context an agent needs to pick this tool correctly: the allowed-list constraint, remote-host behavior, and how it relates to the other log/file-reading siblings.

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 schema already documents host, log_path, last_lines, and first_lines in detail, including their mutual exclusivity. The description adds no parameter meaning beyond that, so the baseline 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 states a specific verb and resource ('Read a specific log file'), so the basic operation is clear. However, it does nothing to distinguish this tool from close siblings such as read_file, get_journal_logs, or get_service_logs, which an agent must choose between. Minimum-viable clarity with a clear sibling-differentiation gap.

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?

There is no guidance on when to use this tool versus read_file, get_journal_logs, or get_service_logs, nor any mention of prerequisites such as the allowed-list restriction on paths or the SSH requirement for remote hosts. The agent is left to infer usage entirely from the schema and sibling names.

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