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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the status_token requirement, the enumerated lifecycle states (which appear nowhere in the schema), and the rule that a consultation counts only when confirmed. The trailing 'no lawyer pays for placement or ranking' sentence is trust boilerplate rather than call behavior and dilutes the signal slightly.

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 deprecation notice and routing instruction are correctly front-loaded, but the closing sentences about listing-service status and paid placement are irrelevant to invoking this tool and add noise. The long parenthetical enumeration of lifecycle states is dense inside a single sentence.

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?

With an output schema present, return values need not be explained, and the tool itself is simple (two parameters). The description covers the deprecation window, the token requirement, and status semantics, which is enough to call it correctly. Only the off-topic marketing sentence keeps it from being fully complete.

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 only 50%: status_token has a schema description, referral_id has only a regex pattern. The description says it 'needs the private status_token', which adds the privacy nuance and hints at a second required input not reflected in the schema's required list. That is useful but minimal compensation for the referral_id gap.

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 plainly that this is a deprecated alias of get_contact_request_status and that it reports what happened with a message the person sent, including lifecycle_state and the lawyer's response. The purpose is clear and the successor sibling is named explicitly, so an agent can tell it apart from get_referral_status or get_contact_request_status. It loses a point because the primary framing is 'older name' rather than a positive statement of what the tool does.

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?

It gives both a when-to-use condition ('the person asks what happened with a message they sent') and an explicit routing instruction to prefer get_contact_request_status until the 2026-12-15 sunset. The two instructions sit in slight tension (use this tool / use the other one), but the deprecation intent is unambiguous. No prerequisites or exclusion cases beyond the redirect are given.

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