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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it respects account visibility (so results may be filtered by permissions) and warns that CRM field values are untrusted user content. This goes beyond the annotations and helps the agent interpret results safely.

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?

Two sentences, both purposeful. The first states the operation and scope; the second is a security warning that applies to all CRM data. No filler or repetition of schema details.

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 simple read tool with one required parameter and readOnly annotations, the description is nearly complete. The main missing piece is clarifying that 'id' is the contact id, and there is no output schema to describe the return shape. However, the tool name and sibling context (set_contact_account) make this inferable, and the visibility note adds important context.

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 description coverage is 50%: the workspaceId parameter is documented in the schema, but the required id parameter has no description. The tool description does not explain what 'id' refers to (presumably the contact id), so the agent must infer it from the tool name. This is a gap, but the schema's workspaceId description and the tool name provide enough context for a baseline score.

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 states a specific verb ('Read'), a specific resource ('accounts associated with a contact'), and a scope qualifier ('respecting account visibility'). This clearly distinguishes it from sibling tools like set_contact_account (write) and get_record (generic read).

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 implies this is the read counterpart to set_contact_account and is appropriate when you need a contact's accounts. It does not explicitly state when not to use it or name alternatives, but the verb 'Read' plus the resource scope gives clear context. The security note about CRM field values also signals a caution relevant to using this tool.

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