aws_elb

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. 'Manage' implies both read and write operations, but the description doesn't specify what permissions are required, whether operations are destructive, what error conditions might occur, or what the response format looks like. For a tool with 11 parameters and complex operations, this is a significant gap in behavioral information.

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 extremely concise at just 4 words, with no wasted language. It's front-loaded with the core purpose. While it's under-specified, it's not verbose or poorly structured.

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 complex tool with 11 parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what operations are available, what parameters mean, what the tool returns, or any behavioral characteristics. The description fails to provide the necessary context for proper tool 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?

With 0% schema description coverage for 11 parameters, the description provides no information about any parameters. It doesn't explain what 'action', 'region', 'name', 'lbType', or any other parameters mean or how they should be used. The description fails to compensate for the complete lack of parameter documentation 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 'Manage AWS Elastic Load Balancers' states the resource (AWS Elastic Load Balancers) and a general action ('Manage'), but it's vague about what specific operations are included. It doesn't distinguish this tool from sibling AWS tools like aws_ec2 or aws_s3, which also manage AWS resources. The verb 'Manage' is too broad to clearly indicate the tool's specific capabilities.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for use, or comparisons with sibling tools like aws_ec2 or aws_vpc. There's no indication of when this tool is appropriate versus other AWS management approaches.

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