call_crosstab

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

With no annotations, the description fully discloses the tool's behavior: it fetches calls, returns a matrix, includes live calls by default, lets users exclude in-progress calls via exclude_status, and explains the caveat about paid attribution data and Google withholdings. This goes well beyond minimal disclosure.

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 longer than typical but each sentence adds useful context, from the high-level purpose to specific dimension nuances and the 'in progress' behavior. It is front-loaded with the main purpose, though the dimension list and caveats add length that could overwhelm if read in full.

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 9 parameters, no annotations, and an output schema, the description addresses nearly every operational aspect: how to filter, what the matrix layout is, which dimensions exist, data attribution caveats, and handling of live calls. It is thorough enough to guide effective use without further documentation.

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?

Although schema coverage is 0%, the description compensates by explaining account_ids, date range (start_date/end_date or time_duration), max_calls, exclude_status, and rows/cols defaults and allowed values. However, it does not explain the account_status parameter or the expected format for account_ids (e.g., comma-separated vs. repeated), leaving a minor gap.

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 opening sentence 'Build a source × status crosstab matrix across sub-accounts' uses a specific verb and resource, and the description expands on the output format and intended use case. It clearly distinguishes from siblings like call_disposition_report by framing this as a single-call aggregation across sub-accounts.

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?

Explicitly states it's designed for a specific question ('break down call volume by source and status for accounts X, Y, Z this week') and contrasts with 'fanning out multiple filtered disposition reports.' It also provides concrete guidance on date formats, max_calls, and exclude_status, covering when to use each.

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