list_ec2_instances

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 does well by specifying the output format `[state] type id name (private_ip)`, the per-account grouping with running/stopped tally, and the effect of omitting account_id. It does not mention pagination or failure behavior, but for a read-only summary tool the disclosed behavior is substantial and sufficient.

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 compact and well-structured: purpose first, then output shape, then parameter semantics. Every sentence earns its place, and the Args section is cleanly separated from the behavioral overview. No redundant or filler content exists.

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 two-parameter listing tool with an output schema present, the description covers the required inputs, default behavior, output formatting, and grouping semantics. The only minor omission is sorting/pagination detail, but the output schema and simple nature of the tool make the definition complete enough for correct 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%, so the description must fully compensate for the bare input schema. It does: account_id is explained as an 'Internal account id from list_aws_accounts' with the default sweep behavior, and region is clarified with an example 'us-east-1'. This adds real meaning beyond property names and defaults.

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 opens with a specific verb and resource: 'Summarize EC2 instances' and clarifies the scope as 'for one account or across all of them.' It also distinguishes itself as a 'Convenience view over aws_ec2_instance' with a defined output shape, so an agent can separate it from broader cloud resource 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?

The description gives clear usage context: omit account_id to sweep all accounts, or provide it to filter to one account. It references list_aws_accounts as the source for valid account ids. However, it does not explicitly state when to prefer this tool over alternatives like query_cloud_resources or list_cloud_resource_types, so it misses the 'when-not-to-use' guidance.

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