transactions_export_async_start

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

The description accurately notes the async nature and the response format, which goes beyond annotations. Annotations indicate it's a non-read-only, non-idempotent, non-destructive operation, and the description does not contradict this. It could improve by detailing that the job runs asynchronously and requires polling.

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: two sentences plus a link. It front-loads the core purpose and return value, contains no filler, and every sentence adds value. The link to full documentation is appropriate.

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 20 parameters and no output schema, the description should cover the async workflow. It mentions returning an ID for polling but does not explain the subsequent steps (status check via transactions_export_async_status, download via transactions_export_async_download). This omission leaves the agent without a complete understanding of the process.

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 tool description does not add new parameter-level meaning beyond what is already provided in the input schema. The schema itself has 60% description coverage with descriptions for many parameters (e.g., text, accept, startDate). The description only mentions 'accept' in passing, so it meets the baseline for high schema coverage.

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 'Start an async transactions export job' and specifies the return value as '{export:{id}}' for polling. It distinguishes itself by mentioning the asynchronous nature and the accept parameter for format selection, leaving no ambiguity about the tool's core function.

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 tells you to use it to start an async export and poll the returned ID, but it does not compare with siblings like transactions_export_sync or transactions_list. There is no explicit guidance on when to choose this tool over alternatives, which is needed given the large sibling list.

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