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

With readOnlyHint/destructiveHint already covering the safety profile, the description goes further: it discloses that it reads a local mirror and calls no CRM API, that it returns every catalogued field including custom fields a preview sample leaves empty, and that a missing record yields a 404 distinguishing 'wrong id' from 'unsynced record'. These are behavioral traits the annotations do not carry.

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?

Front-loads the core purpose and keeps every sentence functional, but it is verbose for a single-record read and uses all-caps emphasis that borders on repetitive. The reference-following and comparator content justify their space; a phrase like 'spends nothing and changes nothing' partially restates the annotations.

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 3-param, all-required read tool with full schema coverage and annotations covering safety, the description rounds out what is needed: return content ('every catalogued field'), the no-API/no-cost behavior, and error semantics. No output schema exists, but the return shape is described well enough.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it clarifies that record_id is an id the caller already holds, and shows how object_type/record_id are chained across calls when following a reference like account_id. Enum values and required fields are left to the schema.

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?

States a specific verb (Read) and resource (ONE record's fields) and immediately scopes it as a single-record lookup keyed by a known id. It explicitly contrasts itself with count_crm_records, so an agent can separate the two siblings without opening either schema.

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?

Gives explicit when-to-use framing ('what does this contact look like', a question about a named record rather than a population), a named negative alternative ('IT IS NOT count_crm_records'), and a follow-up pattern for chasing references ('a contact's account_id names its account... two calls of this tool'). Nothing material is left to inference.

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