accesso_get_wallet_passes

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

Annotations already mark the tool read-only and open-world, and the description adds helpful context beyond that: the returned items are links intended to be opened on a phone, and pass availability depends on merchant enablement. This sets accurate expectations for the output and for cases where passes may be unavailable, without contradicting 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 three short sentences with no filler: the main deliverable is stated first, followed by how it is used and a relevant caveat. Every sentence adds information an agent needs.

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-only tool with no output schema, the description explains what is returned (Google Wallet save links) and the main caveat (merchant enablement). It does not specify the exact return shape or behavior when passes are not enabled, but the combination of description, annotations, and full schema coverage makes the tool callable without major gaps.

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 the parameters are already well documented: url is optional when ACCESSO_TICKET_URL is set, and indexes filters by ticket index values. The tool description does not add further parameter-level meaning beyond restating the order/ticket scope, so the schema carries the load.

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 identifies the resource (Google Wallet save links) and the scope (tickets on an accesso order), so an agent can tell this apart from tools that return order or ticket data. It lacks an explicit action verb like 'returns' and does not explicitly name sibling distinctions, but the meaning is unambiguous.

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 implies when to use the tool: to get Google Wallet passes for tickets on an order, and it notes the limitation that not every merchant enables passes. It does not explicitly state when not to use it or mention an alternative such as accesso_save_barcodes when passes are unavailable, so usage guidance is only implied.

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