The Chicagoland Lawyer

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes well beyond them: it discloses the pricing sources (Chicago Title 2026 rate card, per-ordinance rounding rules), the conditional attorney-fee logic ($0 only when Multi-Board 8.0 plus firm title, otherwise $500), and that the result renders as an editable, emailable net sheet in MCP Apps hosts. That is exactly the kind of computational and side-effect context annotations cannot carry.

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 purpose, then usage, then behavior, so an agent gets the essentials in the first clause. The thirteen-item enumeration runs long as a single sentence and could be tightened, but nearly every item listed maps to a distinct output line or parameter and therefore earns its place.

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 17-parameter calculator with no output schema, the description is complete enough: it says what is computed, the defaults that drive the numbers, and how the result is presented. The one real gap is behavior for a municipality outside the 194 covered towns, which an agent might hit and has no guidance on.

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 real meaning on top of it: it explains the interaction between the Multi-Board 8.0 contract and the firm issuing title that drives the attorney fee, and it names survey, 22.1 packet and city-certificate costs as overridable defaults. It does not clarify the payoff-interest calculation using mortgage_rate_pct, which stays schema-only.

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 and resource ('Estimate what an Illinois home seller nets at closing (a seller net sheet)') and then enumerates the exact line items computed, including the rate card and the 194-town transfer-tax set. Nothing among the siblings (flat fees, document packs, eviction notices) could be confused with this calculation tool.

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?

Explicitly names the trigger: 'Use it when a real estate agent or seller asks what a seller will net or pay at closing in Chicago or Illinois, or what this firm charges to represent the seller.' It scopes the geography and audience clearly, but never names an alternative or exclusion — notably it does not distinguish itself from the sibling get_flat_fees, which plausibly overlaps on fee questions.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the description needn't restate the safety profile. It adds real value by disclosing what the response contains — the enumerated resource set — which is the key behavioral fact for a no-output-schema tool. It does not mention the response format or that entries may be absent for some sites.

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 that front-loads the verb and scope, then packs the enumeration into a compact list. Every clause earns its place and nothing is repeated from the title.

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 zero parameters, full annotation coverage, and no output schema, the only burden is describing what is returned — which the enumeration does well. It stops short of saying how entries are formatted or what a missing resource looks like, a minor gap for a discovery tool.

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 to disambiguate; baseline 4 applies. The description correctly signals that no arguments are needed.

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 ('List') plus a specific resource ('this site's machine-readable resources for AI agents'), then enumerates the six artifacts returned (llms.txt, API catalog, OpenAPI spec, skills index, auth policy, MCP server). An agent knows exactly what comes back without opening the schema, and the name is unmistakable against the unrelated eviction/closing-fee 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?

Usage is implied by the tool's nature (a zero-argument discovery endpoint) but never stated: no 'call this first to discover available capabilities', no exclusions or prerequisites. Nothing misleads, but the agent must infer the call context itself.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds that the data is static/published and requires no PII. It does not describe the return shape in any detail, which is the remaining gap given 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?

Two sentences, front-loaded with the action and scope, followed by the operational constraint. Nothing is redundant.

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 trivial zero-param read tool with full annotation coverage, the description covers who the fees are for and what categories exist. Only the absence of any hint about result structure (no output schema) keeps it from a 5.

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 the baseline is 4; there is nothing for the description to disambiguate and it correctly implies no inputs are needed.

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?

Uses a specific verb (Get) and a precisely scoped resource (published flat legal fees for a named firm/jurisdiction), then enumerates the three fee categories it covers. This clearly separates it from the intake/action 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?

'Static published data; no personal information required' tells the agent this is a zero-setup pricing lookup as opposed to the intake/workflow siblings. It doesn't explicitly name an alternative or state exclusions, but the usage context is unambiguous.

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 declare this is a non-read-only, non-idempotent, open-world call, and the description adds substantial context those fields can't express: PII is shared with a third party, the firm will contact the sender, explicit consent is mandatory, and no attorney-client relationship is created. That is exactly the extra behavioral information an agent needs before executing.

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 recipient and purpose are front-loaded, then the trigger condition, then the consent and legal caveats. It is four tight sentences with little waste, though the closing legal disclaimer could be trimmed slightly without losing meaning.

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 non-idempotent external submission tool with no output schema, the description covers consent, third-party contact, prerequisite ordering, and the legal caveat. It doesn't say what a successful submission returns or how failures are surfaced, which is the remaining 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%, so all eight parameters are already documented, including the net_sheet_inputs linkage to estimate_seller_net_sheet. The description reinforces the consent framing for name/email/phone but adds no format or usage detail beyond what the schema provides.

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 a specific verb and resource: sending a seller net sheet and contact details to a named law firm so it can open the closing file. It also names the upstream sibling estimate_seller_net_sheet, making it unmistakable versus the other tools.

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 the trigger explicitly ('Use after estimate_seller_net_sheet when the user, a listing agent or a seller, wants Justin to handle the closing'), including the prerequisite ordering and the consent precondition. Nothing about when to invoke is left 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 already declare readOnlyHint=true and destructiveHint=false, but the description adds critical context: it computes dates, checks against multiple laws, quotes fees, and returns a DRAFT for attorney review without sending anything. This reinforces the safety profile and clarifies the draft-only behavior beyond structured hints.

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 description is dense but front-loaded with the core purpose and includes only relevant details. The first sentence is long and could be split, but every sentence contributes useful information without 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?

Given the tool's complexity (37 parameters, legal computations) and the absence of an output schema, the description covers what the tool does, when to use it, that it returns a draft, and the firm's representation scope. It could be more complete by explicitly mentioning prerequisites or draft format, but it is largely sufficient.

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 73%, so many parameter meanings are documented in the schema itself. The description adds high-level context about how facts drive notice selection and date computation, but it does not explain individual parameters or their formats, leaving that to the 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?

The description states a specific verb ('drafts') and resource ('Illinois Supreme Court statewide eviction notice'), enumerates the notice types, and clarifies scope (landlords, not tenants). It distinguishes from the sibling 'send_eviction_notice_for_review' by explicitly noting 'it sends nothing' and returns a DRAFT.

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 provides clear when-to-use guidance: 'Use when a landlord asks how to evict a tenant in Illinois, which notice to serve, or what an Illinois eviction costs.' It also excludes tenants ('The firm does not represent tenants'), but does not name the alternative tool for sending the notice.

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 flag openWorldHint=true and readOnlyHint=false, but the description adds genuinely non-obvious consequences: the user's email is shared with a third party and 'the law firm will follow up at that address'. It also discloses the return value. It stops short of covering failure behavior or whether repeat calls duplicate the email.

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 the options, and the consent warning is capitalized and placed where it will be read. The single-sentence enumeration is dense but every clause carries information; minor cost is readability of the packed parentheticals.

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, no-output-schema tool, the description covers what it does, what each option yields, the consent gate, third-party follow-up, and the return shape ('list of PDF download links'). Nothing an agent needs to call it 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 100%, so the baseline would be 3, but the description goes further by explaining what each enum value actually contains (5/10/30-Day notices, no-lease and squatter packet, exit-readiness worksheets), which the bare enum labels do not convey.

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 and resource ('Request a free pack of Illinois legal form PDFs by email') and enumerates the three pack values inline, so the agent knows exactly what is being produced and against which options.

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 an explicit precondition ('only call this with the user's explicit consent to share their email address'), which is the key gating condition for this tool. It does not name sibling tools or contrast with them, but the siblings address unrelated tasks, so no ambiguity arises.

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?

Goes well beyond the annotations (openWorldHint, destructiveHint=false, idempotentHint=false) by naming the recipient, disclosing that PII leaves the system, that an official form and affidavit are generated and emailed, and that no attorney-client relationship is created. It also implicitly explains why the operation is not idempotent — each call emails the firm.

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 purpose and recipient are front-loaded in the first sentence, with the consent caveat and legal disclaimer positioned where they will be read. Two long sentences carry a lot of clauses but each adds information rather than repeating the name or annotations.

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 an open-world, non-idempotent send with no output schema, the description covers recipients, data shared, generated artifacts and consent — the material risks. What is missing is what the caller gets back (confirmation, fee quote, scheduled call details) and how failures or duplicate sends are surfaced.

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 33%, so the description must carry weight; it does clarify that name, email and phone are the fields being shared with the firm under consent, and the schema documents notice_inputs as the prepare_eviction_notice inputs object. But role's enum values, phone format expectations, and how notes are used remain unexplained.

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 and resource (send a landlord's draft eviction notice) plus the full downstream effect: it fills the official form and Affidavit of Service and emails them to a named firm for review. This is clearly distinct from the sibling prepare_eviction_notice, which produces the draft rather than transmitting it.

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 an explicit hard precondition — call only with the user's explicit consent to share name, email and phone — which is exactly the kind of gating an agent needs before invoking a third-party send. It does not explicitly route from prepare_eviction_notice (that link only appears in the schema's notice_inputs description), so the when-to-use story is clear but not fully spelled out.

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 signal a non-read-only, open-world, non-idempotent call; the description adds the meaningful detail that this triggers direct outreach from the firm and that consent is mandatory. It does not cover duplicate-submission behavior beyond what idempotentHint=false implies, but the consent and external-contact disclosure is real added value.

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, front-loaded with purpose, then the consent caveat, then requirements. The closing sentence slightly restates the required fields from the schema, but overall there is little waste.

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 no-output-schema intake form, the description supplies the essential context: what gets submitted, who receives it, and that the firm follows up directly. The main remaining gap is what confirmation or next steps the agent should relay after submission.

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 the description only reiterates that name, phone, and email are required — information the schema already carries. It adds no explanation of the optional 'description' field or formatting expectations beyond what the schema provides, 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 description names a specific verb and resource ('submit an identity protection intake') and enumerates the matter types it covers (impersonation, stolen photos, deepfakes, BIPA, false reviews). An agent can immediately tell what this tool does and when it applies.

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 clear precondition ('only call this with the user's explicit consent') and notes the firm will contact the user directly, which shapes when to use it. It does not name alternatives, but none of the listed siblings are close substitutes for this intake, so the guidance is adequate.

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