iaas_get_external_network_ip_range

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that: the trailing 'GET /iaas/api/external-network-ip-ranges/{id}' duplicates the annotation title verbatim and says nothing about not-found behavior, error responses, or the shape of the returned record.

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 and the resource is front-loaded, but sentence two is a near-verbatim repetition of sentence one and sentence three repeats the annotation title, so roughly half the text is redundant rather than earning 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-by-id operation with full annotation coverage and a 100%-documented two-parameter schema, the definition is adequate to invoke correctly. However, since no output schema exists, the description should give at least a hint of what the returned IP-range record contains (CIDR, IPAM provider, associated network) — that gap is unaddressed anywhere.

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% — both `id` and `apiVersion` are documented in the schema, including the path marker and the versioning reference. The description's 'with a given id' adds no syntax, format, or sourcing guidance beyond what the schema already states, 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 verb+resource ('Get ... external IPAM network IP range') is stated and the object is specific, but the second sentence merely rephrases the first ('with a given id'), and nothing distinguishes it from the sibling list tool iaas_get_external_network_ip_ranges or from iaas_get_internal_network_ip_range beyond the resource noun. It is clear but essentially restates the tool 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?

There is no explicit when-to-use statement, no mention of the list counterpart as the alternative, and no prerequisites. The only usage signal is the implicit 'fetch one by id' conveyed by the endpoint path, which the agent must infer.

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