Pacemaker MCP

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates that the cluster stack is started and does not mention that this mutates cluster state, may require elevated privileges, or affects services on the node.

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 with no wasted words. The phrase 'via pcs cluster start' is somewhat redundant with the tool name, but the overall length is appropriate.

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 thin command wrapper with self-describing optional parameters, so the description is enough to identify intent. However, it lacks behavioral context such as state change, permissions, and effects on the node, which would matter given no annotations or output schema.

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 each of the 5 parameters is already documented. The description adds no parameter-specific meaning, but the baseline applies because the schema adequately covers semantics.

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 action ('Start'), the target resource ('cluster stack'), and scope ('on the node'), which differentiates it from the stop/status sibling tools. It does not explicitly name an alternative, but the verb and resource are specific enough to avoid ambiguity.

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 is given on when to use this tool versus pcs_cluster_stop or the status commands. It also omits prerequisites such as cluster membership, node requirements, or permission considerations. Usage is only implied by the word 'Start'.

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 no annotations provided, the description carries the full burden of explaining behavior. It discloses the underlying command and the state items the agent can expect. However, it does not mention connection/auth behavior, sudo usage, or explicitly confirm the operation is read-only, though 'displays' and 'status' imply a non-mutating check.

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 concise sentences with no filler. The primary action is front-loaded, and the second sentence contributes useful information about the output scope and appropriate use case.

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 the tool's core read-only purpose and the cluster state information returned. However, with no output schema and no annotations, return format, error behavior, and connection prerequisites remain unspecified, and the large undocumented parameter set leaves notable gaps.

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 very low (11%), with only `cluster` documented, and the description adds nothing about any of the 9 parameters. Connection-related parameters such as host, username, password, privateKeyPath, and timeoutMs are left unexplained, so the low schema coverage is not compensated.

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 the specific action ('Displays high-level cluster state'), the exact command used (`pcs cluster status`), and the key areas covered (Pacemaker, node membership, fencing/stonith, manager health). This makes the tool's focus clear, though it does not explicitly differentiate it from sibling tools like `pcs_status` or `pcs_status_full`.

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 a clear intended use case: 'quick health checks.' The phrase 'high-level cluster state' also implies it is not intended for detailed resource or node inspection, but it does not name alternatives or state explicit exclusion conditions.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core effect—stopping the cluster stack—but does not mention that this is disruptive to cluster availability, whether sudo is needed (despite a sudo parameter existing), or what happens if the cluster is already stopped. This is minimal disclosure for a state-changing tool.

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 with no filler. It states the action, the object, and the underlying command efficiently.

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 disruptive operation with no annotations and no output schema, a one-sentence description is under-specified. It does not explain cluster impact, prerequisites, expected behavior, or consequences, so an agent cannot fully assess what invoking this tool will do.

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?

All five parameters already have descriptions in the schema, so schema coverage is 100% and the schema does the heavy lifting. The description adds no parameter-level detail beyond naming the underlying command, which keeps this at the baseline.

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 ('Stop'), a clear object ('the cluster stack on the node'), and names the underlying command ('pcs cluster stop'), so the agent can understand the action. It does not explicitly contrast itself with siblings like pcs_cluster_start, though the inverse relationship is fairly obvious.

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 alternatives such as pcs_cluster_start, pcs_cluster_status, or node-level operations like pcs_node_standby. The intended use case is only implied by the action itself; no prerequisites, contexts, 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?

With no annotations, the description carries the behavioral burden, and it does disclose the underlying command and scope. The verb 'List' conveys a non-mutating read operation, and naming the exact pcs subcommand adds useful behavioral context without contradicting any 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?

The description is a single, focused sentence with no filler. It front-loads the primary purpose and adds the specific command and constraint scope efficiently.

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 list tool with no required parameters and no output schema. The description provides the essential operational detail — the exact pcs command — and the schema covers all invocation parameters, making it 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?

Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The description adds no extra meaning about sudo, cluster selection, timeouts, or SSH config behavior, 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?

The description uses a specific verb ('List') and resource ('all constraints') and identifies the exact command, 'pcs constraint config', including common constraint types. This clearly differentiates it from sibling commands like pcs_resource_list or pcs_property_list.

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 reasonably implied: an agent would use this when it needs to inspect constraints. However, the description provides no explicit guidance about when to prefer this over related status/config sibling tools, and no exclusions are mentioned.

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 are absent, so the description must carry the full burden of behavioral disclosure. It reveals a read operation ('retrieve') but does not explicitly state whether it is read-only, whether it requires elevated permissions (though a sudo parameter exists), what specific log files are considered 'common,' or the exact behavior of the journal snippet inclusion. The lack of detail on side effects, prerequisites, or return format is a significant gap.

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, well-formed sentence that conveys the core purpose without unnecessary fluff. It is appropriately succinct and front-loads the primary action and resource, making it easy to scan. No word 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?

Given that there is no output schema, no annotations, and a relatively complex tool with 7 parameters, the description is far too brief. It does not explain what 'common' logs means, how the journal snippets are selected, what format the output takes, or how the parameters affect behavior. An agent cannot confidently determine what this tool returns or how to tailor a call for a specific need. The presence of specialized siblings also demands clearer scoping.

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 provides descriptions for all 7 parameters, covering 100% of them. The description only adds the phrase 'optional journal snippets,' which loosely maps to includeJournal but does not explain the parameter semantics beyond the schema. Since the schema already defines each parameter, the description adds minimal additional meaning, warranting the baseline score of 3.

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 action (retrieve) and the resource (common Pacemaker/Corosync logs) with a modifier (common) that hints at a standard set. However, it does not explicitly differentiate from the sibling tools pcs_logs_tail and pcs_logs_journalctl, which likely serve narrower purposes. The phrase 'optional journal snippets' suggests a combined scope, but without further detail the distinction from siblings is left to inference.

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 is given on when to use this tool versus its siblings pcs_logs_tail or pcs_logs_journalctl. The description does not state what scenarios favor this tool (e.g., 'use this when you need a broad overview of logs') or when to choose the more specialized tools. The agent is left without explicit routing advice.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the operation is a read (non-mutating) via 'Read' and adds the useful default-units behavior. However, it does not disclose remote execution implications, sudo requirements, or what happens if no units are specified, so some transparency gaps remain.

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 concisely states the operation, the underlying command, and the default behavior. Every word earns its place with no padding 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?

Given the tool has no required parameters, a fully self-documenting schema, and no output schema, the description is minimally adequate. It does not explain how this tool relates to the sibling log tools or provide usage context that would help an agent choose between them, so it is complete enough for basic invocation but not fully contextual.

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 every parameter. The description adds only one semantic detail beyond the schema: that the tool defaults to pacemaker and corosync units. This is useful but not substantial enough to raise the score above the baseline for high 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?

The description states a clear action ('Read journal logs via journalctl') and specifies the default scope ('pacemaker and corosync units'). This is specific enough to identify the tool's purpose, though it does not explicitly name or contrast sibling log tools like pcs_logs_tail or pcs_logs_common.

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 is provided on when to use this tool versus alternatives. The phrase 'defaults to pacemaker and corosync units' implies a typical use case, but there is no explicit when-to-use, when-not-to-use, or alternative tool mention, leaving the agent to infer selection criteria.

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 no annotations provided, the description carries the behavioral burden. It explicitly discloses that missing files are skipped, which is a non-obvious behavior an agent needs to know. The wording 'Tail last N lines' also clearly conveys a read-only operation, and there is no indication of hidden side effects.

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 short sentences with zero filler. The core operation is front-loaded, and the behavioral exception ('Skips missing files') is added efficiently without 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?

For a read-only log tailing tool with a fully documented 7-parameter schema, the description is nearly complete. It covers the core operation and an important edge case, though it does not mention output format or explicitly how multiple paths are handled beyond 'one or more.'

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 parameters are already fully documented. The description reinforces that paths are log files and that operation is per-file tailing, but it adds little semantic detail beyond the schema. Baseline 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 a specific verb and resource: 'Tail last N lines from one or more log file paths.' It is unambiguous about what the tool does, but it does not explicitly differentiate itself from sibling tools like pcs_logs_journalctl or pcs_logs_common.

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 when you need the last N lines from log file paths, and mentions that missing files are skipped, which is helpful context. However, it provides no explicit guidance on when to choose this tool over sibling log tools or what circumstances would favor pcs_logs_journalctl.

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 no annotations provided, the description carries the full burden, and it does disclose the core behavioral outcome: resources no longer run on the node. However, it omits other behavioral traits such as reversibility, impact on resource movement, permissions, or error 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 a single focused sentence with no filler. It front-loads the action and effect, then gives the command syntax efficiently.

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 operation is simple and all six parameters are described in the schema, so the agent can invoke it correctly. However, the absence of annotations, output schema, and any mention of revert behavior or side effects leaves some contextual gaps for a mutating cluster command.

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 baseline is 3 even though the description adds little beyond the command placeholder '[<node>]'. The node parameter semantics are already fully documented in the schema; the description does not materially augment them.

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 action ('Put a node in standby') and the affected resource (node), and the parenthetical '(no resources run there)' clarifies the operational effect. It does not explicitly distinguish itself from the sibling pcs_node_unstandby, but the command syntax makes the action 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?

The description includes the command form 'pcs node standby [<node>]', but gives no guidance about when to use this tool versus alternatives such as pcs_node_unstandby or resource-level controls. It does not mention prerequisites, expected conditions, 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?

With no annotations present, the description carries the full burden of behavioral disclosure. It indicates a non-mutating read operation by using 'Shows' and 'Lists', and it names the underlying command. However, it does not mention that the tool likely connects to a remote host, may use sudo, or requires cluster/credentials, which are relevant behavioral aspects hinted at by the schema.

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

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

The description is two concise sentences with no filler. It front-loads the main purpose, provides the underlying command, and then specifies the output contents, making it easy to scan and understand quickly.

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 has nine connection/authentication parameters, no output schema, no annotations, and many sibling status tools, the description is too sparse to be fully actionable. It explains what the tool returns at a high level but omits the invocation model, credential handling, default host/cluster behavior, and output format details.

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 0%, and the description provides no parameter information whatsoever. With nine parameters including host, port, sudo, cluster, password, username, timeoutMs, passphrase, and privateKeyPath, the description does not compensate for the schema gap by explaining connection semantics, defaults, required options, or how credentials interact.

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 shows node states using the concrete command 'pcs status nodes', and it lists the specific categories of state information returned (online/offline, standby, maintenance, unavailable). This distinguishes it from siblings like pcs_status_resources or pcs_status by specifying the exact resource and command.

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 the tool is for checking node-level status, particularly when the agent needs online/offline, standby, or maintenance state. However, it gives no explicit guidance about when to prefer this over pcs_status, pcs_status_resources, or pcs_cluster_status, and it does not mention alternatives 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?

No annotations exist, so the description alone must disclose side effects, but it only restates the command 'pcs node unstandby [<node>]'. It does not state whether this triggers cluster reconfiguration, requires privileges, or what failure modes occur.

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 no filler; the action and command are immediately visible.

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 tool is a simple state-changing command with no output schema and no annotations, and the description does not cover when to use it or the effects of the operation on the cluster. The missing context beyond the schema makes 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%, so the schema already documents node, sudo, cluster, timeoutMs, sshConfigHost, and sshConfigPath. The description adds only the [<node>] syntax, matching the node field, with no extra meaning.

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 names the specific operation 'Bring a node out of standby' and gives the exact command form, so an agent knows the tool reverses standby. This distinguishes it from the sibling pcs_node_standby without needing to open schemas.

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 indicates when to choose this over pcs_node_standby or status tools; the usage is only implied by the verb. An agent must infer the precondition that the node is in standby and that other status/management tools serve different purposes.

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 no annotations, the description carries the burden. 'List' and the exact 'pcs property list --all' command clearly indicate a non-mutating read operation, so an agent can infer it is safe. It does not detail permissions or failure modes, but for a simple list operation the core behavioral trait is disclosed.

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 front-loads the command and purpose with no redundant words. Every element contributes useful 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?

For a read-only, no-required-args list tool, the description supplies the command, scope (--all), and intended use. It omits output shape details, but no output schema exists and the list semantics are reasonably inferable, making this largely 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?

All five parameters are documented in the input schema (100% coverage), so the description is not required to restate them. It adds no parameter-level detail beyond the schema, which is 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?

Description states a specific verb and resource: 'List cluster properties via pcs property list --all', which unambiguously identifies the operation. 'For tuning and defaults' adds a clear purpose and differentiates this from sibling status/resource/constraint tools.

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?

'For tuning and defaults' gives an implied use case, but the description does not explicitly state when to prefer this tool over siblings or mention any exclusions. There is no alternative routing, so guidance is minimal.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It only repeats the command syntax and does not explain the side effects of banning a resource, such as creating a location constraint, whether the ban is persistent, whether special permissions are required, or how it can be reversed. For a mutating operation this is a significant gap.

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 one tight sentence that front-loads the action and target. The command syntax is useful and there is no filler or redundant 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?

The tool has 8 parameters, no output schema, and no annotations, yet the description covers only the core command shape. It omits behavioral context such as what the ban does in the cluster, expected outcomes, failure modes, or how this differs from related constraints. An agent could invoke it based on the schema, but not fully understand the consequences.

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 baseline is 3. The description adds the command-level argument ordering and marks lifetime as optional, but it does not materially add meaning beyond the schema's own parameter descriptions.

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 action ('Ban'), a clear resource ('a resource'), and a scope ('from a node'), and it gives the exact pcs command syntax. This separates it from sibling operations like move, clear, enable, disable, and unban by naming the ban operation explicitly.

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 is provided on when to use this tool versus alternatives such as pcs_resource_move, pcs_resource_clear, or pcs_resource_unban. The usage context is only implicit in the word 'ban'; there are no explicit when-to-use or when-not-to-use conditions.

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 no annotations, the description must disclose side effects, but it only says 'cleanup' without explaining that this is a mutating operation that resets failcounts/failure history and could influence resource placement. This is a meaningful transparency gap for a production-cluster command.

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 one tight sentence and front-loads the action before the command syntax. It is appropriately concise, though brevity comes at the cost of missing behavioral context.

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 mutating Pacemaker command with no annotations and no output schema, this description is incomplete: it lacks side effects, prerequisites, and differentiation from pcs_resource_clear. The schema covers connection parameters, but not operational semantics.

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 documents all six parameters with descriptions, so the baseline applies. The description adds no parameter detail beyond the schema, though it echoes the key 'resource or all' behavior.

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 identifies a specific verb ('Run cleanup'), a resource target, and the exact CLI invocation, so an agent can infer this is the resource-cleanup operation. It does not define what cleanup does (reset failcounts/failure history) nor contrast itself with the similarly named sibling pcs_resource_clear.

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 is given on when to invoke cleanup versus the closely related clear/restart/enable operations. The description only states the command and leaves the situational context 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core operation but does not disclose side effects, scope of cleared constraints/failures, idempotency, required privileges, or whether this is destructive. For a mutating tool this is a meaningful transparency gap.

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 with no filler. The inline command syntax is slightly redundant with the tool name but is short and useful for grounding the operation.

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 that this is a mutating command with no annotations and no output schema, the description is minimal. It does not explain what happens after clearing, what prerequisites exist, or how the operation interacts with cluster state, leaving an agent under-equipped for error handling and validation.

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 all six parameters. The description only echoes the resource parameter via the command syntax and adds no additional meaning beyond the schema, matching the baseline of 3.

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 identifies a specific action ('clear') applied to a resource and states the effect ('temporary constraints and failures'). It is more specific than a tautology and is distinguishable from siblings like pcs_resource_cleanup by mentioning constraints as well as failures, though it does not explicitly differentiate itself.

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 this tool should be preferred over related tools such as pcs_resource_cleanup, pcs_resource_unban, or pcs_resource_disable. The description implies a recovery scenario but provides no exclusions or alternative routing.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. 'Show' and the quoted 'pcs resource config <id>' command make the read-only intent apparent, and the description explains what the output includes. It does not explicitly say 'no cluster state is modified' or address authentication, but that is a minor gap for a display command.

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 with no filler: the command and scope are front-loaded, and the second sentence concisely lists the output categories. Every sentence 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 show-config tool, the description plus the fully covered schema gives an agent the required ID, the exact command, and the expected output categories. It could have added an explicit read-only/no-side-effects statement or pointed to pcs_resource_list for discovering IDs, but the core invocation is well covered.

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?

All six parameters have schema descriptions, so the baseline is 3. The description reinforces that 'resource' is the target ID and adds that only that resource's data is returned, but it does not add meaningful semantic detail beyond what the schema already provides.

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

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

The description uses a specific verb ('Show') and a precise resource ('configured definition for a specific resource') while naming the exact underlying command. The phrase 'for that resource only' clearly differentiates it from cluster-wide status or list siblings.

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 it clear this tool is for inspecting a single resource's configuration rather than cluster-wide state, and that the resource ID is required. It does not explicitly name alternatives like pcs_resource_list or state when not to use this tool, so it stops short of full routing 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the core disable action but does not mention side effects, reversibility, permission requirements, impact on running services, or command output. For a mutating operation this is a significant gap.

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 conveys the core operation and command form without filler. It is front-loaded and 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?

Given no annotations and no output schema, the description is too sparse to be complete. It fails to mention when to use this vs. enable/move/ban, what happens after disabling, whether it is reversible, or what the command returns. The high schema coverage helps with parameters but not with behavioral or operational 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 the schema already documents all parameters. The description adds only mild value by showing the command syntax and suggesting that 'resource' and 'all' are alternative ways to target the operation. This is useful but not extensive.

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 action ('Disable'), the target ('resource or all resources'), and the exact command syntax. It differentiates this tool from the sibling enable/move/ban tools by making the disable operation explicit.

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 is provided about when to use this tool instead of alternatives like pcs_resource_enable, pcs_resource_move, or pcs_resource_ban. The description implies use for disabling resources but gives no exclusions, prerequisites, or context for choosing among siblings.

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 no annotations and no output schema, the description must carry the burden of behavioral disclosure. It reveals the underlying CLI command but does not disclose side effects, whether the action is idempotent, whether it immediately starts the resource, or whether sudo/remote-host behavior changes the outcome.

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 contains no filler. Every part earns its place: the action, the target, and the exact invocation syntax.

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 mutating operation with no annotations and no output schema. The description plus schema is enough to construct an invocation, but it leaves important context undefined: success/failure behavior, cluster impact, whether 'all' conflicts with 'resource', and whether sudo is needed. For a mutation tool, this is an incomplete agent-facing contract.

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 baseline is 3. The description adds minor value by showing the mapping between 'resource' and '<id>' and 'all' and '--all', and implying either one is used, but it does not explain exclusivity or the SSH-related parameters.

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 ('Enable'), a resource ('a resource or all resources'), and even the exact CLI invocation, making the tool's purpose immediately clear. It distinguishes itself from siblings like pcs_resource_disable and pcs_resource_restart without ambiguity.

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 intended use is implied: use this when you want to enable a resource or all resources. However, it does not explicitly contrast with alternatives, such as when to use pcs_resource_restart instead, nor does it state prerequisites or whether enabling is for previously disabled resources.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. 'Shows' implies a read-only operation, but the description does not explicitly confirm it makes no cluster changes, does not mention connection/authentication requirements, and provides no detail on command execution, output size, or potential failures.

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 one focused, front-loaded sentence that names the command and the returned contents without fluff. It could earn a 5 if it also added the missing usage/safety guidance without becoming verbose.

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 tool has no output schema, no annotations, and 9 undocumented parameters, yet the description only covers the config content and a high-level use case. It omits connection semantics, required inputs, output format, and relationship to sibling commands, so it is not complete enough for reliable 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?

Schema description coverage is 0%, and the description does not explain any of the 9 parameters (host, port, sudo, cluster, password, username, timeoutMs, passphrase, privateKeyPath) or how they interact. The description adds no meaning beyond the bare parameter names in the schema.

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 clear verb ('Shows') and a specific resource ('full resource configuration'), and enumerates the content included (agents, parameters, operations, meta-attributes, groups, ordering/colocation metadata). It does not explicitly distinguish itself from the sibling pcs_resource_config, so it loses the top score.

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 phrase 'for troubleshooting and audits' gives a clear use context, but the description does not state when to prefer this tool over siblings such as pcs_status_resources, pcs_constraint_list, or pcs_resource_config, nor does it mention when not to use it.

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 no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that the tool does not directly move the resource but creates a temporary location constraint, which is non-obvious. However, it does not mention side effects on the cluster, whether the constraint persists until cleared, or whether the move is asynchronous.

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, well-structured sentence that front-loads the core behavior and then provides the exact command syntax. There is no wasted text or repetition of schema 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?

For a cluster-mutating tool with no annotations and no output schema, the description is too thin. It omits usage context, cleanup/lifecycle implications, potential prerequisites like a running cluster, and any distinction from related constraint-management 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 coverage is 100%, so the baseline is 3 because all parameters are already documented. The description only lightly echoes the <id> and <node> placeholders and adds no new semantic detail beyond the schema.

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 a specific action: 'Create a temporary location constraint via pcs resource move <id> [<node>]', which goes beyond the tool name by explaining the underlying mechanism. It is reasonably distinct from siblings like pcs_resource_clear or pcs_resource_ban, though it does not explicitly contrast against them.

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 guidance on when to use this tool versus alternatives such as pcs_resource_ban, pcs_resource_clear, or pcs_resource_restart. The phrase 'temporary location constraint' implies a preferred use case, but the description never states when not to use it or what cleanup might be required.

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 no annotations, the description carries the full burden of behavioral disclosure. It reveals the core command behavior but does not mention that restarting a resource may cause transient service disruption, that omitting the resource will restart all resources (a potentially dangerous action), or that sudo or cluster authorization may be required.

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 sentence with the command syntax front-loaded and no redundant content. The phrase 'agent-dependent' is somewhat vague and slightly undermines precision, but the overall structure is efficient.

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 state-changing tool with no annotations and no output schema, the description omits important operational context such as side effects, prerequisites, and expected result behavior. It is especially under-specified because omitting the resource can restart all resources, which an agent needs to recognize as a high-impact action.

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 meaning beyond the schema by explaining that omitting the resource parameter results in restarting all resources, which the schema's 'Optional resource ID to restart' does not fully convey. The connection-related parameters are already well documented in the schema.

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 the action ('restart'), the target resource, and the exact command syntax, and it notes the all-resources behavior when the resource is omitted. It is clearly identifiable from read-only sibling tools, though it does not explicitly distinguish itself from other state-changing siblings like pcs_resource_cleanup or pcs_resource_move.

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 alternatives such as pcs_resource_cleanup, pcs_resource_enable, or pcs_resource_move. The phrase 'agent-dependent' is vague and does not clarify intended invocation conditions. The usage context is only weakly implied by the tool 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the intended action but does not mention side effects, such as the resource becoming eligible to run again, permission requirements, or success/failure behavior. For a mutating operation, this is a significant transparency gap.

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 sentence with the core action front-loaded and no filler. It is appropriately concise, though it could have used a code block or slightly more detail without becoming verbose.

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 schema fully documents parameter semantics, so the invocation is straightforward. However, with no output schema and no annotations, the description does not explain return values, prerequisites, or post-conditions. It is minimally viable but leaves gaps for an autonomous agent deciding whether the operation succeeded or what side effects occurred.

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?

All 7 parameters are already fully described in the schema, so the baseline is 3. The description's command template reinforces the role of the resource and optional node parameters but adds no new meaning beyond what the schema provides.

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 and object — 'Remove a ban for a resource' — which clearly distinguishes it from pcs_resource_ban and other resource actions. It also includes the exact CLI command pattern, adding execution detail beyond the tool name. It is slightly tautological since the name already conveys 'unban', but it still clarifies the resource scope.

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 does not state when to use this tool versus alternatives such as pcs_resource_clear, pcs_resource_enable, or pcs_resource_ban. There is no explicit context about when a ban should be removed or what conditions make this the right choice. The only guidance is implied by the command name and syntax.

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 no annotations, the description carries the full burden of behavioral disclosure. It does convey that the tool runs 'pcs status' and produces a summary of cluster components, but it does not explicitly state that the operation is read-only, whether it executes over SSH, or what output format is returned.

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 states the command, the purpose, and the key output contents without filler or redundancy. Every part adds 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?

The tool is simple, has zero required parameters, and its schema covers all parameters. However, with no output schema and no annotations, the description could do more to explain the return format, the read-only nature, and how this tool differs from pcs_status_full and pcs_status_xml.

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 parameter semantics baseline is 3. The description adds no information about the five parameters, which is acceptable because the schema already documents them adequately.

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 summarizes overall cluster status and names the output categories: nodes, resources, failures, and constraints. It is more specific than a bare rephrasing, but it does not explicitly distinguish itself from closely related siblings like pcs_status_full, pcs_status_xml, or pcs_cluster_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 phrase 'Overall cluster status' gives implied context for when to use the tool, and the word 'summarizes' suggests a high-level overview. However, there are no explicit when-to-use/when-not-to-use instructions or named alternatives, leaving sibling selection somewhat to inference.

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 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.

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

With no annotations, the description carries the full behavioral burden. It communicates a read-only status operation via 'shows', but it does not disclose remote SSH execution, sudo implications, or any cluster prerequisites. Some behavioral transparency exists, but operational detail 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?

The description is a single front-loaded sentence that states the command and its core output semantics directly. There is no filler, repetition, or unnecessary detail.

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 output semantics are summarized well, but with no annotations and no output schema, the description omits alternative routing among similar status commands and any remote-execution or output-format context. It is adequate for a simple status tool, but not fully 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?

All five parameters are already fully described in the input schema with 100% coverage. The description adds no parameter-level meaning, which is acceptable per the baseline, but it also offers no extra nuance about the SSH/connection parameters.

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 ('shows'), names the exact command ('pcs status resources'), and specifies the resource-level content: started/stopped state and node placement. This clearly distinguishes it from configuration-oriented siblings like pcs_resource_config.

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 narrow scope implies when to use it—when resource runtime state is needed—but there is no explicit when-to-use or when-not-to-use guidance. Given the many overlapping siblings like pcs_status, pcs_status_full, and pcs_resource_list, explicit alternative routing is missing.

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 no annotations, the description carries the behavioral burden itself. It discloses that the tool returns cluster status in XML via a specific command, which is meaningful, but it does not explicitly state read-only behavior, output size, failure modes, or whether sudo/SSH handling affects execution.

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, tightly worded sentence with no filler. It front-loads the core purpose and includes the exact command and intended use, making it efficient for an agent to scan.

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 tool with no annotations and no output schema, the description is somewhat minimal. It communicates the command and output format but lacks detail about what the XML contains, how it should be parsed, or how this differs concretely from sibling status tools. It is adequate but not comprehensive.

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 documented. The description itself adds no parameter-level meaning beyond what the schema provides, matching the baseline for high 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?

The description clearly identifies the resource (cluster status), the output format (XML), and the underlying command ('pcs status xml'). It conveys the tool's purpose, though it lacks an explicit action verb and does not directly name or contrast sibling tools like pcs_status or pcs_status_full.

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 phrase 'for programmatic parsing and deeper diagnostics' implies when this tool should be used, which is helpful but not explicit. It does not state when to choose pcs_status_xml over sibling status tools or when not to use it.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the show action and command, and adds no information about output format, side effects, permissions, or how remote execution parameters like sudo or sshConfigHost affect the operation.

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 one concise sentence with no filler. It front-loads the core action and target, and the reference to the underlying pcs command is useful without being verbose.

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 no annotations and no output schema, the description is too thin to fully orient an agent. It omits return-value expectations and usage context, and does not clarify how the five generic SSH/cluster parameters apply to this specific stonith read command.

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?

All five parameters already have descriptive schema fields, so the baseline is 3. The description adds no additional meaning to the parameters; 'including configuration and parameters' refers to the displayed stonith configuration, not to the input parameters.

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 identifies a specific operation ('show') and a specific target ('stonith/fencing devices'), and names the underlying command ('pcs stonith show'). It is clear enough to distinguish from generic status commands, but it does not explicitly differentiate from closely related resource/status siblings.

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 alternatives. With many sibling read commands such as pcs_status_resources and pcs_resource_config, the description should at least hint at the conditions that make this tool the right choice.

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