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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the safety bar is lower. The description still adds real value: the one-time matter_token that must be stored, the fact that no attorney-client relationship exists until signature, that the principal must sign, and the fee timing. However, the surrounding legal/confidentiality boilerplate is largely duplicated from the matter_summary schema description, diluting the added behavioral context.

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 precondition and the core action, then walks through the flow and return values without much waste. Some sentences about confidentiality and the absence of an attorney-client relationship repeat the schema text and could be trimmed.

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?

There is no output schema, and the description fully covers the return values (matter_id and a once-shown matter_token) plus the full lifecycle after submission — review, scoping questions, accept/decline, letter to the principal's email, fee on delivery. Nothing an agent needs to call this correctly is missing.

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 75%, so the schema already documents most parameters, and the description's guidance on matter_summary ('describe the product the way you would describe it publicly', 'do not send code, secrets, user data, or confidential business plans') is copied verbatim into the schema's own description rather than adding new meaning. conflict_check_id and principal_email receive no additional explanation in the description.

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 action — send a matter_summary so the attorney can decide whether to take the matter — and ties it to a precondition (after conflict_check). An agent can tell this is the intake/engagement-request step rather than a conflict lookup or a status check, though it does not explicitly distinguish itself from submit_intake.

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 ordering ('After conflict_check') and describes the downstream path: attorney reviews, may ask scoping questions via get_matter, then accepts or declines. It does not state when not to use this tool or how it differs from submit_intake, but the sequencing guidance is concrete.

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