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

Goes well beyond readOnlyHint: it states the tool 'runs nothing that changes the node', discloses that repeated calls attach to an in-flight fetch rather than dispatching a duplicate, explains why the failure is invisible to every other tool (cloud-init's growpart fallback masking a failed carve), and notes the SSH-via-bastion transport. This is exactly the extra context annotations cannot carry.

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 and dense: the what, the when, the return, and the exclusion all appear in the first half. The long growpart-fallback parenthetical is the only stretch that reads as tangential, though it justifies why the tool exists at all.

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 output schema, the description still specifies the return payload (cloud-init's own status including whether it errored, plus the output-log tail). Combined with the availability limits, node identification guidance, and no-mutation guarantee, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented; the description only echoes the node_id-preferred-over-node_name choice and adds the provenance hint that node_id comes from list_cluster_nodes. That is a marginal addition over structured data, 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?

Opens with a specific verb+resource: read cloud-init status and the tail of /var/log/cloud-init-output.log for one node of an Ankra-provisioned cluster. It names the provider set (Hetzner, OVH, UpCloud, DigitalOcean, Scaleway) and the access path (SSH-via-bastion), so an agent can distinguish it from the large family of get_* readers without opening 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?

Gives an explicit trigger ('Use it when a node group carries user_data and a node came up wrong') with concrete symptoms (missing partitions/mounts, absent package, first-boot script whose effect is absent), an explicit exclusion ('Not available for imported or managed-Kubernetes clusters'), and names the alternative for adjacent cases ('For OS-level failures unrelated to first boot, use ssh_diagnose_node').

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