list_billing_transfer_end_customers_by_reseller

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the 'same result as GET /billingtransfer/v1/end-customers' context and the callability constraint, which is useful. However, it doesn't disclose behaviors like pagination, filtering defaults (includeRevoked), or what happens if the caller lacks permission, which would be valuable beyond the 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 compact with two sentences, efficiently delivering purpose, equivalent endpoint, and callability. It's front-loaded with the action (list) and resource. Minor deduction for the API endpoint reference which, while useful, could be considered an extra detail not essential for all agents, but overall it's well-structured and to the point.

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 a simple purpose, no output schema, and moderate parameter complexity, the description provides adequate context: what it lists, how it's identified, and who can call it. However, it lacks information about return format or pagination, which for a list operation could be important. Still, annotations cover safety, and the description covers identity and access, so it's reasonably 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?

The schema description coverage is only 25%, meaning most parameters lack descriptions. The description compensates partially by highlighting the key parameter resellerPmaAccountId and its role in identity. However, it does not explain includeRevoked, X-Tenant-Id, or customerContext behavior beyond what the schema already provides for customerContext. The baseline is 3 because schema coverage is low, but the description doesn't fully annotate the other parameters, so it stays at 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 tool lists AWS billing-transfer end customers by reseller PMA account ID, and explicitly references the equivalent API endpoint. It distinguishes itself from sibling tools like list_billing_transfer_reseller_accounts and list_billing_transfer_program_management_accounts by naming the specific resource (end customers) and the identifier used. However, it's slightly less precise than a direct 'List end customers' phrasing because it begins with the broader domain manage and includes an API reference.

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 clear context: it lists end customers identified by resellerPmaAccountId alone, eliminating the need for dpmaId. It also specifies callability (reseller owning PMA or distributor owning DPMA), which gives clear usage guidance. While it doesn't explicitly name alternative tools for comparison, it implies the scope is narrower by referencing the API endpoint, which helps the agent decide when to use this tool.

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