get_call

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

With no annotations available, the description carries the full burden of behavioral disclosure. It reveals the non-obvious large default payload (~100+ fields) and explains how the 'fields' parameter truncates the response, which is critical operational knowledge. It does not mention permissions or error handling, but these are not prominent concerns for a read-only retrieval tool.

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 moderately sized but front-loads the primary purpose. Each sentence delivers operational value—large payload warning, field-filtering optimization, and alternative tool referral—without redundancy. It could be slightly tightened, but the structure is logical and scannable.

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?

With an output schema present, return shape is already documented. The description covers the main contextual concerns: default response size, parameter filtering behavior, and alternative tool selection. It does not detail error cases or authentication, but these are not major gaps for a straightforward single-call retrieval tool with an output schema.

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 input schema provides only names and types with 0% description coverage. The description compensates by thoroughly explaining the 'fields' parameter, including comma-separated format and examples of valid top-level keys. The required call_id and account_id are self-evident identifiers from the tool name, so the description adds sufficient semantic value for the most complex parameter.

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 opens with a specific verb and resource ('Get details for a specific call'), clearly indicating single-record retrieval. It also differentiates from the sibling call_disposition_report by explicitly directing bulk analysis elsewhere, establishing its scope as individual call detail access.

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 explicitly advises using call_disposition_report for bulk disposition analysis, providing a clear alternative and exclusion condition. It also gives practical usage tips (pass 'fields' to reduce payload when checking several calls), giving the agent concrete guidance on when and how to use the tool.

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