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

With no annotations, the description carries the full burden and does well: it discloses the precondition (engagement must have begun), the repeats-on-change pattern, and a hard rejection rule ('a fact package that contains a name, an e-mail address or a postal address ... is refused'). It stops short of describing what a successful submission returns or whether resubmission overwrites prior facts.

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 payload shape and timing, then the exclusions, which is the right order. The final sentence restates the refusal condition already implied by 'do not send ... any name, e-mail address or postal address', costing some redundancy.

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 three-parameter mutation with a free-form nested object, no annotations, and no output schema, the description covers shape source, preconditions, forbidden content, and the expected failure mode. Only the success response and idempotency behavior remain unspecified, which is a minor 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 coverage is 100% for matterId/matterToken, but the facts object is untyped (additionalProperties: {}), so the schema cannot document it. The description compensates with real field-level rules: omit counterpartyLegalName, never send names/e-mails/postal addresses, and use "the Client"/"the Customer"/"the Vendor" conventions — meaning an agent could not derive from structured fields alone.

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 identifies the resource precisely (the fact package for the DPA/agreement) and ties its shape to the "dealroom.solo-intake/1" schema from get_dpa_requirements, which separates it from the sibling get_dpa_requirements and from the generic submit_facts. However, the opening sentence describes the payload rather than stating the action, so the verb (submit/send) is only implied by the tool name and title.

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 states exactly when the call is accepted — only after the engagement has begun, and again on lawyer request for changes — and routes the agent to get_dpa_requirements first to learn the payload shape. Both the timing condition and the prerequisite lookup are explicit, leaving nothing to inference.

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