Get PCP performance summary

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.