North End Law

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

Annotations already cover the read-only safety profile, and the description adds genuinely new behavioral context: the result is only meaningful after a lawyer releases it, it contains placeholders rather than real party data, and the finished PDF/Word document is available only on the private page and signing e-mail. That tells the agent what it cannot retrieve here, which is valuable. It stops short of 5 because it doesn't say what happens if the agreement isn't yet released.

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?

Two sentences, with the availability precondition front-loaded before the content description and the PDF/Word contrast. Slightly unusual colon construction in the first sentence, but no wasted text.

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 compensates by characterizing the returned format (Markdown, placeholder tokens, blank addresses/signatures). Combined with readOnlyHint, an agent knows enough to call it and interpret the result; only the not-yet-released failure behavior is unaddressed.

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%, and both matterId and matterToken are documented as coming from open_matter, so the schema carries the weight. The description adds no meaning about parameters beyond that, making the baseline 3 appropriate.

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 concretely states what comes back: the agreement in Markdown with placeholders and blank signatures, and contrasts it with the final PDF/Word version that lives elsewhere. The verb is only implicit (the title supplies 'Fetch'), and it does not explicitly distinguish itself from siblings like get_engagement_terms or get_requirements, so it falls short of a 5.

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 one real precondition — 'Once a lawyer has released it' — and a purpose ('so you can explain it to the user'), which implies when to call it. However, it never names an alternative or an exclusion against the other get_* tools, leaving routing largely to inference.

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

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

Annotations only declare readOnlyHint=true; the description adds a real workflow precondition about not submitting facts before the engagement begins, which is context the annotation cannot carry. It doesn't describe what the returned schema looks like or whether narrowing alters its shape, so it is useful but not complete.

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?

Three short sentences: identity of the resource first, optional narrowing second, the precondition last. No filler and nothing buried.

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 two-optional-enum read tool with no output schema, the description covers purpose, narrowing behavior, and a key precondition, and it names the output format as a JSON Schema. Only the default (un-narrowed) result and the schema's shape remain unstated.

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?

With 50% schema coverage, the description compensates by explaining the effect of both parameters – that governing law and role optionally narrow the result set – which the schema's enum lists alone do not convey. It still doesn't clarify the default behavior when both are omitted.

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+resource ('the facts the data processing agreement needs') and the return type ('as a JSON Schema'), which distinguishes it from the submit_* siblings that instead send those facts. An agent can tell it apart from get_requirements and submit_dpa_facts without opening a schema.

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?

Explains the optional narrowing by governing law and role, and adds an ordering constraint ('Do not send the facts until the engagement has begun') that implies a separate submission step. It stops short of naming submit_dpa_facts as the alternative, so the sibling routing is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description earns credit by disclosing what the payload contains (version, SHA-256 hash, acceptance flag). It stops short of covering failure modes, e.g. what happens when the terms are not open for acceptance or unavailable.

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?

A single sentence, front-loaded with the resource, enumerating the return contents without filler. Nothing can be trimmed without losing information.

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 no output schema, the description is the only source of return info and it does describe the payload components adequately for a read-only getter. It is short of fully complete in omitting behavior when the document is missing or not yet available for acceptance.

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 'tool' parameter is enum-documented as dpa/baa in the schema itself. The description's phrase 'for a service' loosely frames the parameter but adds no new semantics beyond the schema, so the baseline 3 applies.

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 names the resource precisely (the full limited-scope engagement text for a service) and lists the exact payload components: version, SHA-256 hash, and acceptance status. However, it uses 'engagement terms' and 'service' while the parameter enum is dpa/baa and the sibling get_dpa_requirements covers adjacent ground, so the agent gets clear purpose but not a clean separation from siblings.

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?

There is no when-to-use guidance at all, and no explicit mention of the closely related sibling get_dpa_requirements, which an agent could easily confuse with this tool. The only usage signal is implied by the getter framing.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description isn't carrying the safety burden. What it does add is the shape of the response — status narrative, next human step, business-hour target, lawyer question — which has value because no output schema exists, but it says nothing about freshness, polling behavior, or what happens with an invalid/expired token.

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?

A single compact sentence-fragment with no filler, front-loading the most important element (where the matter stands). It is tight, though its telegraphic phrasing ("the target in business hours") costs clarity rather than words.

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 no output schema, the description is the only source of return-value information, and it nominally covers the four things returned. But it is too terse to fully serve that role: "the target in business hours" is ambiguous (target date? SLA?), and nothing is said about error handling or whether the status changes over time.

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% and both parameters are documented as coming from open_matter, so the schema does the work. The description adds no information about matterId or matterToken (e.g., token being single-use), so baseline 3 applies.

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 name and title say "matter status," but the description itself never states a verb or that it retrieves anything — it reads as a bare list of returned fields ("Where the matter stands, the next human step, the target..."). An agent can infer it reads a matter's status, but the purpose is only implied and no sibling is distinguished.

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?

There is no indication of when to call this versus alternatives such as get_deliverable or get_requirements, nor any prerequisite (e.g., that a matter must first be opened). The mention of the lawyer's question hints at a polling/check-in use case but never states it.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful traits: the $350 full charge at checkout, the full-refund conditions, the acceptance precondition, and that the link is e-mailed to the named person. It omits the most decision-critical behavior for an unannotated tool — whether invoking it is a read-only retrieval or itself triggers a charge, and whether the link expires or is reusable.

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?

Three sentences with no gross padding, but the opening leads with product and pricing context instead of the tool's action, and the final sentence about e-mail delivery is secondary information placed where the return value should be. The structure is serviceable but not front-loaded on what the agent must decide.

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 two-parameter, fully documented, unannotated tool, the description should settle the read-vs-charge question and indicate the return value (a URL). Neither is addressed, leaving the agent unable to predict the effect of calling or what it receives, which is the main gap this description needed to close.

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%, so both matterId and matterToken are already documented as coming from open_matter. The description adds no parameter-level meaning and its reference to 'the named person' does not map to either parameter, so the schema baseline of 3 applies.

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 (the firm's card payment page for $350) and its preconditions, but never states the action the tool performs — nothing says it returns or generates a link URL. The 'get_' name and the described resource make the intent inferable, but the purpose is left implicit rather than stated as a verb+resource.

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 a real precondition — usable only once the named person has accepted the engagement — which narrows when to call it. However, it names no alternatives and no exclusions, so the agent gets implied rather than explicit guidance on when this beats talking to the user directly or checking get_matter_status first.

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

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

readOnlyHint=true is consistent with a read/fetch operation, so the safety profile is already covered by annotations. The description adds real value by disclosing the response shape (a JSON Schema) and a pre-condition tied to engagement start, but says nothing about whether the schema varies by governing law or how large/complex the output is.

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?

Three short sentences with the resource and return format front-loaded, followed by the narrowing behavior and the prerequisite. Slightly awkward opening clause but no filler.

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 only one required parameter, no nested objects, and no output schema, the description covers what an agent needs: what comes back (JSON Schema), the two service variants, optional narrowing, and the precondition on submitting. The main gap is the unaddressed relationship to get_dpa_requirements.

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 67% and the description compensates by explaining conditional applicability: role and governingLaw only matter for a DPA and "narrow" the result. That conditional scoping is not expressed in the schema, which just lists them as flat optional properties. It does not list the governingLaw enum values (CALIFORNIA/SPAIN), but the schema does.

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 names the resource precisely (the facts a service needs) and states the return format is a JSON Schema, plus enumerates the two service variants. It does not, however, differentiate itself from the very similar sibling get_dpa_requirements, leaving ambiguity about which to call.

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 one useful workflow constraint ("Do not send the facts until the engagement has begun"), which implicitly points at submit_dpa_facts/submit_facts. But it never says when to use this general tool versus the DPA-specific sibling, and the sequencing rule is about a different tool rather than about selecting this one.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds no behavioral context beyond that — no auth requirements, pagination, or freshness guarantees. The second sentence is contact metadata about the responsible lawyer, not behavior of the tool, so it does not raise this score.

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 first sentence is well front-loaded and compact. The second sentence is a full postal address for the responsible attorney, which is unlikely to help an agent select or invoke this tool and dilutes the description's signal.

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 zero-parameter, read-only catalog tool with no output schema, the description should at least characterize the return shape (a list of services with price and jurisdiction fields). It gestures at this via 'at what fixed price, under which laws,' but never states the structure of the response, leaving a modest 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description's 'at what fixed price, under which laws' hints at what the returned entries contain, which is a modest bonus but not parameter semantics.

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 the resource clearly — the firm's service catalog with fixed prices and governing laws — and the title supplies the 'list' verb. It is distinguishable from sibling tools like get_engagement_terms or get_payment_link, which retrieve a single item rather than the whole offering. It lacks a crisp first-person verb (e.g., 'Lists all services...'), which keeps it out of 5 territory.

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?

There is no statement of when to call this versus the sibling getters, nor any prerequisite or exclusion. An agent must infer that this is a first-stop catalog lookup. No guidance is provided about whether it should precede open_matter or request_consultation.

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

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

With no annotations, the description carries the full burden and does so: pricing, what happens after the call (user opens a private link within 24 hours), what the agent never sees, conflicts-check outcomes, and refund behavior. The one-time nature of the matter token is an important operational warning that the schema does not convey.

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 action and price, then requirements, then return/flow. Every sentence carries information, but the long parenthetical-heavy middle sentence and the engagement/refund explanation make it denser than necessary for a five-field tool.

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?

No output schema exists, yet the description names the return values (matter id, one-time token, private link) and explains the downstream human workflow that determines whether the engagement is accepted. Nothing an agent needs to call this correctly or set user expectations 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 100%, so the baseline is 3, but the description adds cross-parameter meaning: the BAA forces CALIFORNIA-only law and BUSINESS_ASSOCIATE with receivesPhi false, and it restates the defaults in prose. Much of this duplicates the schema text, which keeps it from a 5.

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?

Opens with a specific verb and resource ("Starts a request for a data processing agreement") and immediately names the variant switch (tool "baa") plus the price. It also distinguishes itself from the sibling request_consultation at the end, so an agent can route without opening the schema.

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?

Spells out exactly which fields to send, explicit prohibitions ("Do not ask the user for, and do not send, any name, e-mail address or postal address"), naming conventions, and a clear alternative ("A vendor whose services handle protected health information should use request_consultation"). Both the when and the when-not are present.

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

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

With no annotations, the description carries the full burden. It does disclose the key behavioral fact that submitting triggers a notification to the firm and yields a booking link, plus a confidentiality caution, but says nothing about follow-up timing, whether a record is persisted, or what happens on invalid input.

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?

Two short sentences, zero waste, with the scope condition front-loaded before the behavioral outcome and the input caution. Nothing could be removed without losing information.

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 3-required-parameter write-side tool with no annotations and no output schema, the description covers the trigger condition, the outcome, and the confidentiality constraint. It leaves gaps around what the caller receives back and what the firm does with the request, which matters because no structured field supplies that context.

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 only 33% (only 'topic' is described), so some compensation is required. The description reinforces 'topic' as a one-line, non-confidential input and adds a meaningful constraint, but adds nothing about 'name' or 'email' beyond what their field names and formats imply.

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 a concrete action chain: it returns a booking link and notifies the firm that a person wants to talk. The scope clause 'for anything outside the listed services' implicitly separates it from list_services and the submit_*/open_matter siblings, though no sibling is named explicitly.

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?

'For anything outside the listed services' gives a clear triggering condition, and 'Send a one-line topic only, no confidential facts' sets a usage constraint on the input. It stops short of naming which sibling to use instead when the request falls inside the listed services.

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

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.

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 acceptance preconditions, that a package containing a name/e-mail/postal address held for the matter is refused, that counterpartyLegalName must be omitted because the firm supplies it, and an extra BAA/PHI restriction. It stops short of describing what a successful submission returns or how refusals are surfaced, which matters since there is no output schema.

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?

Content is front-loaded as a single dense paragraph: identity and shape first, then acceptance rules, then content restrictions. The prohibition on names/e-mails/addresses is restated for both "do not send" and "will be refused," which is mild redundancy but each clause adds a distinct nuance (interaction vs. validation).

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 4-required-parameter mutation with a nested open-ended object, no annotations and no output schema, the description covers preconditions, content rules, exclusions and refusal behavior. The remaining gap is the response/error contract, which nothing else in the structured data supplies.

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%, so the enum and id/token parameters are already documented; the description's added value is on the free-form nested `facts` object, where it prescribes substitute wording ("the Client", "the Customer"/"the Vendor") and exclusions. That meaningfully constrains the one parameter the schema leaves as additionalProperties, exceeding the baseline 3.

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 ("the fact package for the matter's service") and its schema id, but never states a verb — the action is only carried by the name and title. It also does not distinguish itself from the sibling submit_dpa_facts, leaving the agent to infer which submission tool applies to a given service.

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?

Timing/preconditions are explicit: "Accepted only once the engagement has begun, and again when the lawyer asks for changes," and it points to get_requirements for the shape. It gives clear when-to-call context, but names no alternative when this tool is not the right one (e.g. submit_dpa_facts or open_matter ordering).

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