legal_matter_intake

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

Annotations already carry the mutation/destructive profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false), so the description need not restate those. It adds workflow-level context, but it does not disclose concrete side effects such as whether a persistent matter is created, whether conflicts-check results are stored, or whether the engagement letter/fee proposal is sent anywhere—relevant given the destructive hint.

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 lead sentences are tight and front-loaded, conveying the tool's purpose and main behavioral steps. The Args block is direct and justified because it supplies meaning absent from the schema, though it slightly duplicates property names that the schema already lists.

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?

Output schema exists, so return-value documentation is not required, but the tool has zero required parameters and the description never says which inputs are expected or necessary—e.g., whether message OR client_message/attachments must be supplied, or whether jurisdiction is essential for the conflicts check. For a multi-step legal workflow with destructive annotations, this is a meaningful completeness gap.

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 0%, and the Args block does the compensating work: it defines message as 'free-text objective,' client_message as 'initial client message or summary,' attachments as 'URLs of supporting documents,' and jurisdiction with concrete examples. It does not fully disambiguate message vs. client_message, but each parameter receives meaningful semantics beyond the raw 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?

Description opens with 'Run a new-matter intake from a client message or file'—a specific verb and resource—and then spells out the unique workflow: classifies matter type, conflicts-checks, drafts engagement letter scope, and proposes fee structure. This clearly separates it from sibling legal drafting, review, and matter-creation tools even though no alternative is named.

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 intended context is implied by 'new-matter intake,' but there is no explicit when-to-use or when-not-to-use guidance, nor any reference to sibling tools like clio_create_matter or legal_contract_review. An agent must infer selection criteria rather than being told them.

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