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

With no annotations supplied, the description directly discloses that the tool is read only and explains two important visibility restrictions: calls are owner-or-office only, and prices require price-viewing permission. It also warns that customer wording is wrapped as untrusted text, which is valuable behavioral context for safely interpreting returned content.

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 pre-visit purpose is front-loaded, followed by compact statements about read-only behavior, price permissions, and next_actions. Although the opening content catalogue is long, each item describes a distinct component of this broad aggregate and there is no filler or repetition.

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 complex aggregation tool, the description covers its contents, intended timing, read-only behavior, trust handling, permission boundaries, and advisory next actions; the output schema can supply the exact return structure. It falls short of full completeness because visit_id is not explained in prose and no narrower sibling is identified for agents that do not need the full brief.

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 description never explains that visit_id is the UUID of the visit for which to build the brief. The schema's parameter name and uuid format make this mostly inferable, but with 0% schema description coverage, the prose does not compensate for the missing parameter documentation.

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 identifies a specific resource and purpose: a one-page, pre-visit brief aggregating the visit, customer, address, communications, notes, media summaries, tasks, and related quotes. This breadth clearly distinguishes it from a basic visit record getter such as visits_get, even without naming that sibling.

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 phrase "before a visit" gives an explicit usage occasion, and next_actions is explained as guidance for actions at or after the visit. It does not state when a narrower alternative such as visits_get, phone_calls, or tasks_list would be preferable, so there are no explicit exclusions or routing rules.

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