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

Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable behavioral context: calls charge a fixed cost from daily quota, and explains how to handle partial responses (partial status means trustworthy data with possible missing optional components) and staleness (honor freshness block). This goes beyond 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 concise and well-structured: opening sentence states purpose, followed by execution details, cost, handling of partial status, and then clear Args section. It is front-loaded with essential information and avoids redundancy, though the Args section slightly duplicates the schema.

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 output schema exists (so return format is covered), the description covers all key aspects: recipe execution, cost implications, partial response handling, and dependency on resolve_entity. It provides sufficient context for an agent to use the tool correctly.

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?

Input schema has minimal descriptions (0% coverage in schema), but the description fully compensates by explaining both parameters: recipe is 'from the fixed manifest' with explicit examples, and entity is a dict from resolve_entity with the required structure. This provides complete guidance for correct invocation.

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's function: 'Composed current view of an entity via a named recipe.' It lists concrete recipe examples (company_snapshot, etc.) and explains the return envelope contents. The purpose is specific and distinguishes from siblings (e.g., get_timeseries gets time series, not snapshots).

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 context on when to use this tool (when a fixed server-side snapshot is needed) but does not explicitly state when not to use it or name alternative tools. It implies usage through recipe names and references to resolve_entity, but lacks direct comparative guidance.

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