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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is well covered. The description adds meaningful context beyond that: it requires a linked PropertyList account (or agency API key), it only ever reads the calling agency's own contacts, and it is scoped to those the caller may see in the CRM. That permission/auth disclosure is real value over the 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?

Front-loaded with the full content picture, then the workflow guidance (where to get the ID and when to call). The long facet list is informative but borders on verbose; still, every clause maps to a returned field, so it earns its place. Slightly dense but well-structured.

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 single-param read tool with an output schema, the description covers purpose, prerequisites, workflow position, and access/permission constraints. The output schema handles return values, so no return-format detail is needed. Nothing material is missing for correct invocation.

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 100% and the single parameter contact_id is already documented in the schema with its origin (find_contacts or my_pipeline). The description reinforces the same source, which is redundant but not harmful. Baseline 3 applies when the schema does the heavy lifting; the description adds no new syntax or format meaning.

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 (get) and resource (contact), and enumerates the returned facets (contact details, pipeline position, agents, saved searches, enquiries, notes, viewings, listings sent, last contact, next booking). This clearly distinguishes it from find_contacts/my_pipeline, which are search tools that locate IDs rather than retrieve the full record.

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?

Explicitly tells the agent where to get contact_id (find_contacts or my_pipeline) and when to call it: 'before advising an agent on a client, and before match_buyer_to_inventory, so you know what has already been sent.' This names the prerequisite and the downstream consumer, which is exactly the routing guidance needed.

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