pcs_status_full

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

With no annotations, the description must convey behavioral traits itself. It clearly indicates this is a status/read-type command by name and lists what is included, but it does not explicitly state that the operation is read-only, uncommonly verbose, or conditional on permissions. The 'history' and 'deep troubleshooting' hints imply a heavy output, but that is not stated directly.

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 a single, front-loaded sentence that names the command, the scope, and the included sections, followed by the intended use case. There is no filler, redundant phrasing, or repetition of schema field names.

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 single-command wrapper without an output schema, the description gives enough content detail (nodes, resources, failures, options, constraints, history) for an agent to understand what it will get. It does not mention output size or parse cost, but the explicit command mapping and inclusion list make the tool sufficiently complete for selection and invocation.

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?

The input schema already provides descriptions for all five parameters, so schema coverage is 100%. The tool description adds no parameter-level meaning, such as which parameters matter for a remote host or whether sudo is typically required. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 command ('pcs status --full') and a clear resource ('full cluster configuration and runtime details'), then enumerates the major content areas: nodes, resources, failures, options, constraints, and history. The word 'Full' plus the content list distinguishes this from the simpler pcs_status sibling and other status-focused tools without needing to open the schema.

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 context ('useful for audits and deep troubleshooting') but never explicitly contrasts it with alternatives such as pcs_status, pcs_status_resources, or pcs_status_xml. An agent can infer when it might be appropriate, but the tool does not explicitly state when to use it or when to prefer a lighter-weight status tool.

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