Evictions API

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the description sensibly spends its words on non-obvious behavior: nothing is submitted, documents must be uploaded via the REST API or the site rather than this server, retries are made safe by reusing an idempotencyKey, and the result carries `state` and `nextAction`. That is meaningful context beyond the annotations. It stops short of describing failure modes or error behavior, which keeps it at a 4 rather than a 5.

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 the 'nothing is submitted' boundary are front-loaded, then constraints, retry safety, the exclusion, the next step, and the auth requirement follow in order. Every sentence carries a routing rule, a constraint, or a prerequisite; none is filler, despite the description being longer than average.

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 12-parameter nested-object mutation with no output schema, this definition supplies everything an agent needs: required inputs, the non-submission guarantee, the idempotency contract, the auth requirement, the sibling to avoid, and a summary of what the response contains (`state`, `nextAction`). No output schema exists, but the description covers the return shape at the level needed to proceed.

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 the baseline is 3 and the schema already carries the field-level meaning. The description nonetheless adds value by enumerating the five required fact groups in plain language and by reinforcing two schema-level instructions that are easy for an agent to skip: always pass and reuse `idempotencyKey`, and treat attestations as the person's own statements rather than something to invent.

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 and resource ('Creates a draft case in the person's account') and immediately bounds the scope with 'Nothing is submitted.' It distinguishes itself from siblings by naming evictions_update_case as the wrong tool for existing cases and evictions_validate_case as the next step, so an agent can route correctly without opening another 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?

It gives an explicit trigger ('when the person wants to start an eviction case and has given you its facts: the ground, where the case starts, the property, the parties and their own attestations'), an explicit exclusion ('Do not use this to change a case that already exists (use evictions_update_case)'), a follow-on action (evictions_validate_case), and a prerequisite (sign-in or an API key). Nothing about when to select this tool 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 readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real behavioral context: an auth requirement (sign-in or API key), and the fact that the attorney field only appears 'for a live case'. That conditional disclosure is exactly the kind of detail annotations cannot 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-loads purpose, then exclusions, then return shape and auth. Each sentence carries routing or behavioral weight, though the return-shape sentence ('facts, deadlines, documents...') is dense enough to be slightly list-like.

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, so the description must describe returns, and it does: facts, deadlines, documents, attorney, plus `state` and `nextAction`. Combined with the auth note and sibling routing, an agent has everything needed to call this correctly.

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 the schema already documents the single `id` parameter including its pattern and provenance. The description's 'Input: the case `id`' restates rather than extends this, 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?

States a specific verb+resource ('get one case in full') and immediately scopes it ('where it stands and what it is waiting on'). It explicitly distinguishes itself from the two closest siblings, evictions_list_cases (finding) and evictions_get_case_events (history).

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 when-to-use ('when you need one case in full') plus two explicit when-not-to-use cases, each paired with the correct alternative tool by name. Nothing 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds substantive context: the visibility filter ('events the person may see'), the sort order ('oldest first'), the per-event payload ('what happened, the state before and after, and when'), and the auth requirement ('sign-in or an API key'). These are behavioral facts an agent cannot infer from the structured fields.

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 tightly packed sentences with zero filler: trigger first, then input, then return shape, then exclusions. Every clause earns its place and the most important routing information is front-loaded.

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 single-parameter read tool with no output schema, the description covers trigger, input, return shape, ordering, visibility scope, auth prerequisite, and sibling routing. Nothing an agent needs in order 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?

Only one parameter and schema description coverage is 100%, so the schema already documents the id, its pattern, and its provenance. The description only restates 'the case `id`' and adds no format or sourcing detail beyond what the schema provides, making the baseline 3 correct.

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 ('what has happened on a case so far'), names the single input, and explicitly distinguishes itself from the closely related evictions_get_case and evictions_list_case_messages. An agent can pick this tool over its 17 siblings without opening any 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?

Gives the triggering user intent ('when the person asks what has happened on a case so far') plus explicit negative guidance naming the two alternative tools and the cases they cover (current status, messages). Both the when and the when-not are stated.

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 cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true). The description adds behavior the annotations cannot convey: the URL is stable while the checkout stays open, the tool refuses when the charge is not due or online payment is disabled, no tool accepts card details, and auth is required.

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 trigger condition, then inputs, then return behavior, then failure modes and auth. Six short sentences, each carrying a distinct operational fact with no padding.

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?

A mutation/action tool with no output schema, yet the description still tells the agent what comes back (a URL), what to do with it (hand it to the person), idempotency behavior, refusal conditions, and auth requirements. Nothing needed 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% and both properties already document their format and source tools, so the schema does the heavy lifting. The description's 'one due charge' restates the schema's 'id of a due charge on that case' rather than adding new syntax or constraint detail; 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?

States a specific verb and resource: 'Opens a hosted checkout for one due charge and returns its URL.' It also names the sibling it is not (evictions_list_case_charges for paid-status checks), so an agent can distinguish it from the other 17 tools 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?

Explicit trigger ('when the person wants to pay a due charge'), explicit exclusion ('Do not use this to see whether a charge is paid'), the named alternative, the required inputs, and the precondition (account via sign-in or API key). Nothing 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds useful extra context: no input required, no auth key needed, and that the returned text is verbatim from the pricing page with its link. It stops short of describing response structure or any rate limits, so not a 5.

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, trigger first, then return contents, then the exclusion. Every sentence carries information and nothing is repeated.

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-param, read-only lookup with no output schema, the description covers the trigger, the absence of inputs, the return payload and its provenance, and the exclusion. Nothing an agent needs to invoke 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?

Zero parameters, so the baseline is 4; the description reinforces this with 'Takes no input,' leaving no ambiguity that the call is argument-free.

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 (returns pricing info) and the exact resource (platform fee, separate costs, refund rule, with link), and names the sibling it is not for. An agent can distinguish it from evictions_list_case_charges without opening either definition.

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 gives the trigger ('when the person asks what a case costs or about refunds') and an explicit exclusion with the correct alternative tool for case-specific charges. Nothing 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, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuine beyond-annotation context: it takes no input, it is unauthenticated ('No key needed'), and the content is served 'in the site's own words' with outbound links. It does not need to describe return formatting 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?

Front-loaded with 'Use this when', followed by what it returns and then the two explicit exclusions. Four sentences, none redundant, and the auth detail is a short trailing clause rather than a paragraph.

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 introspection tool with no output schema, the description covers invocation (no input, no key), output contents (description, status, operator, links), and routing boundaries against both nearest siblings. Nothing an agent needs 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?

The tool has zero parameters, which sets the baseline at 4. The description confirms this explicitly with 'Takes no input', which is accurate and prevents an agent from hunting for an argument object.

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 ('Evictions API' service overview) and enumerates exactly what it returns: the service description, current status, operator, and links to home/how-it-works pages. It explicitly contrasts itself with evictions_get_pricing and evictions_get_state_eviction_facts, so an agent can route without opening any 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?

The description gives the triggering user intent ('what Evictions API is, what is available today, how a real case is handled or who operates it') and then names two exclusions with the sibling to use instead for each. This is explicit when/when-not/alternatives coverage.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral facts: no input is required, no key is needed, and the exact content returned. It stops short of richer operational detail, but for a static onboarding read there is little else to disclose.

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?

Every sentence earns its place and the ordering is front-loaded: trigger condition first, then input/return behavior, then the do-not-use exclusion and the auth reassurance. No filler or repetition.

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, so the description compensates by enumerating the returned artifacts (sign-up link, key types, connection/auth info, doc links), and it also clarifies the auth requirement. An agent has everything needed to call and route this tool correctly.

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 zero parameters the baseline is 4, and the description reinforces this by stating 'Takes no input', which matches the empty schema. Nothing further is 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?

The description opens with a precise trigger (no account or key yet, or asking how to connect an agent) and then states exactly what the tool returns: sign-up link, test/live key explanation, server connection/auth details, and docs/OpenAPI links. This is clearly an onboarding/info tool, easily distinguished from the case-manipulation 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?

It gives both the positive condition ('person has no account or key yet, or asks how to connect an agent') and an explicit exclusion ('Do not use this to check a key the person already has'), naming the alternative behavior of sibling case tools that report missing/refused keys.

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 cover the safety profile (readOnly, idempotent, non-destructive, non-open-world), and the description adds substantial context beyond them: the 90-day staleness cutoff, per-fact citations/source links/dates/quotes, the general-information disclaimer, empty-state behavior, and no-auth ('No key needed'). This is far richer than the annotations alone.

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 usage and densely packed with return-value detail; every clause carries information. It is a single long run-on paragraph rather than cleanly segmented, which slightly hurts scannability but wastes little.

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, so the description carries the full return-shape burden and does so thoroughly: opening answer, verified/sourced facts with citation metadata, staleness rule, page link, disclaimer, and empty-state. An agent has everything needed to call and interpret the result.

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 schema already documents the accepted formats (two-letter code, name, slug) including the DC special case. The description restates 'two-letter code, a name or a slug' without adding format or validation detail beyond the schema, so the 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?

States a specific verb and resource: retrieving how eviction works in one state, with concrete examples (notice for nonpayment, the court). It is clearly distinguishable from siblings such as evictions_resolve_jurisdiction and case-management 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?

Explicitly names the trigger ('when the person asks how eviction works in one state') and two exclusions with alternatives: not for whether a case can be opened (use evictions_resolve_jurisdiction) and not for advice on a particular case. Both when-to-use and when-not-to-use are covered.

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 read-only, idempotent and non-destructive, yet the description still adds real context: auth requirement ('sign-in or an API key'), result ordering ('oldest first'), the per-charge fields returned, the status value set (due, paid, void, refunded), and the online-payment flag. That is substantial disclosure beyond the structured fields.

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 triggering condition, then input, output shape, the sibling exclusion, the follow-up tool, and auth — all in tight declarative fragments with no filler. Every sentence 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?

No output schema exists, but the description enumerates the returned fields and ordering, plus auth and follow-up routing. An agent has everything needed to call and interpret this one-parameter read 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?

Schema description coverage is 100% and the single parameter is fully documented in the schema (format, pattern, provenance). The description only restates 'Input: the case `id`', adding no new format or sourcing detail, 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?

States a specific verb and resource ('Returns the charges on a case') and frames it around the user's question ('what they owe on a case or whether a charge is paid'). It explicitly distinguishes itself from the closest sibling, evictions_get_pricing, so an agent can route without opening either 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?

Explicit when-to-use (owing money / charge status), explicit when-not-to-use ('Do not use this for the published prices (use evictions_get_pricing)'), and a named next step ('Next: evictions_get_payment_link for a due charge'). Nothing 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description still adds ordering (oldest first), per-message shape (author, text, time), and the auth requirement ('sign-in or an API key') that annotations do not express. It stops short of covering pagination or result-size limits for a potentially large message list.

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 trigger condition, then input, return shape, exclusion, next step, and auth in a tight sequence. Every sentence carries either routing or behavioral information; the ordering and 'own and team's' detail both earn their 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?

With no output schema, the description correctly compensates by summarizing the return shape and ordering. Auth prerequisites, the sibling exclusion, and the natural next call are all present, so nothing an agent needs to invoke 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 description coverage is 100% and the single `id` parameter is fully documented in the schema, including its pattern and origin (create_case/list_cases). The description only restates 'Input: the case `id`', adding no syntax or format detail 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?

States a specific verb and resource ('Returns the messages on a case') plus scope ('the person's own and the team's, oldest first'), which no sibling does. An agent can distinguish it from evictions_get_case_events without opening either 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?

Gives an explicit when ('when the person asks whether the Evictions API team has written about a case, or before writing to it'), an explicit when-not with the named alternative ('Do not use this for the case's events (use evictions_get_case_events)'), and a follow-up route ('Next: evictions_send_case_message to reply').

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, and the description goes well beyond them: it discloses the auth requirement ('sign-in or an API key'), the scoping to the key's organization and mode (test or live), newest-first ordering, page-at-a-time behavior, the per-item fields (state, nextAction), and nextCursor being null on the last page. That is substantive context the structured fields do not 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?

Three dense, waste-free sentences cover purpose, inputs, returns, exclusions and auth. Minor deduction: the 'do not use' exclusion arrives after the return-value sentence, so the routing guidance is not as front-loaded as it could be.

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 carries return-shape burden and does so (pagination, ordering, per-item fields, terminal cursor). Combined with the auth note and the sibling routing, an agent has everything needed to call it correctly.

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 both parameters (limit with max/default, cursor) are fully documented in the schema, so the baseline is 3. The description only restates that limit and cursor are optional and that cursor comes 'from the page before' rather than adding format or constraint detail beyond 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 and resource ('the person's cases', 'the id of a case you do not have') and immediately scopes it against the closest sibling by naming evictions_get_case. An agent can distinguish this list tool from the get/create/update siblings without opening any 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?

It gives an explicit use condition ('when you need the person's cases, or the id of a case you do not have') and an explicit exclusion with the alternative named ('Do not use this when you already have the case id (use evictions_get_case)'). This is the when/when-not/alternative pattern in full.

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, and openWorldHint=false, so safety and determinism are covered. The description adds context the annotations don't: 'Takes no input' and 'No key needed', plus the exact result set (50 states and DC). It doesn't mention result size limits or ordering, which keeps it short of a 5.

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 tight sentences: purpose/coverage first, then the input and return shape, then the exclusion. Every sentence carries routing or behavioral information, and nothing is redundant with 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?

No output schema exists, and the description compensates by describing the return payload (50 states plus DC, each with code, name, slug, page). For a zero-parameter lookup tool, an agent has everything needed to select and call it.

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?

Zero parameters, so the baseline is 4. The description correctly reinforces this with 'Takes no input', leaving no ambiguity that this is a call-with-no-arguments tool.

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 (list states) and goes further by enumerating the coverage ('every place the service covers') and the payload fields (two-letter code, name, slug, page). An agent can distinguish it from evictions_get_state_eviction_facts and evictions_resolve_jurisdiction 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?

Explicit when-to-use ('you need every place the service covers, or the exact code or slug of a state') and an explicit when-not-to-use that names the alternative sibling (evictions_get_state_eviction_facts) for single-state rules. This is the exact routing information an agent needs.

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, and non-destructive, so the safety profile is covered. The description adds genuine context beyond them: what the response contains (served status, per-ground required facts, ZZ notice rules under a test key) and that an account via sign-in or API key is required.

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 decision-relevant use case, then inputs, outputs, the exclusion, and the next step. Dense but every clause carries information; minor verbosity in the output description keeps it from a 5.

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 must explain return values and it does (served status, per-ground facts, test-key notice rules). It also covers auth requirements and the downstream tool, leaving nothing essential for correct invocation 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?

Schema coverage is 100% and the schema already documents state, county, and city with examples and the ZZ test-key convention. The description only restates the inputs ('state, and county and city when known'), adding essentially nothing 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?

States a specific verb (resolve) and resource (jurisdiction) and precisely scopes what it answers: whether a case can be opened for a property's location and which facts each eviction ground requires there. It also names the sibling it is not (evictions_get_state_eviction_facts), so an agent can distinguish it without opening schemas.

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 timing ('before creating a case'), an explicit exclusion with the alternative named ('Do not use this for a state's published facts... use evictions_get_state_eviction_facts, which needs no key'), and the follow-on tool ('Next: evictions_create_case'). When-to-use, when-not-to-use, and alternatives are all covered.

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?

Beyond annotations, the description discloses that the team is notified by email, the message is sent in the person's name, test cases are refused, there is a rate limit of 20 per 10 minutes per organization, and the call returns the message as stored. It also specifies the authentication requirement. These are meaningful behavioral details not present in the structured annotations.

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 front-loaded with the primary usage instruction and keeps each sentence focused on a distinct fact. It is somewhat longer than strictly necessary, but no sentence is wasted and the structure remains easy to scan.

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 write operation with no output schema, the description covers the return value, authentication, rate limits, refusal behavior, and the relevant alternative tool. It provides everything an agent needs to invoke the tool correctly without relying on additional structured fields.

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 input schema already fully documents both parameters with patterns and semantic descriptions. The description repeats 'Input: the case id and body' and emphasizes 'Send only what the person asked to say', but adds no new syntax or format constraints beyond what the schema provides. A baseline of 3 is appropriate when the schema does the heavy lifting.

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 and resource: 'Sends the team a message about a live case'. It explicitly distinguishes this from the sibling tool for editing drafts by naming 'evictions_update_case'. An agent can tell exactly 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 explicit when-to-use guidance ('Use this when the person asks you to write to the Evictions API team about one of their live cases') and when-not-to-use guidance ('Do not use this to change a draft (use evictions_update_case)'). It also states prerequisites (sign-in or API key) and operational limits (20 per 10 minutes, test cases refused).

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 flag it as destructive, open-world, and non-idempotent, but the description adds substantial context beyond them: the exact state transition (draft to submitted), that a platform fee becomes a due charge, that a licensed attorney is engaged, that nothing is served or filed before attorney review, and the test-key vs live-key behavior difference. This is exactly the behavioral disclosure the annotations don't 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 the trigger condition ('Use this when...') followed by effects, key-mode nuance, and constraints. Dense and mostly waste-free, though the multiple clauses about attorney engagement and test/live keys make it lengthier than typical.

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?

Covers the trigger, side effects, key-mode behavior, auth requirement ('Needs the person's account: sign-in or an API key'), return value ('Returns the case and its check results'), and the next tool to call. With no output schema, this fully compensates.

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 both parameters are documented in the schema (baseline 3). The description reinforces confirmedByPerson semantics ('Confirm with the person first, then pass confirmedByPerson: true') and adds the important constraint that attestations must be the person's own statements, which goes beyond the schema. Marginal but real added value.

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 ('submitting a draft' of a case) and distinguishes itself from siblings by naming evictions_validate_case as the wrong tool for checking a draft. An agent can identify this as the submission/finalization step 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?

Gives explicit when-to-use ('the person has said yes to submitting a draft that passes every check') and when-not ('Do not use this to check a draft (use evictions_validate_case)'), naming the alternative. It also routes the agent to the follow-up tool evictions_list_case_charges.

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 destructiveHint=true and idempotentHint=true, but the description adds the crucial PATCH semantics ('each one replaces the stored value', whole objects replaced), the draft-only restriction (annotations don't say this), which fields are immutable, the auth requirement, and the returned `state`/`nextAction`. This is substantial context the structured fields do not 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 the when-to-use condition, then input semantics, constraints, result, next step and auth. Dense and well ordered; a couple of clauses (the parenthetical next-action gloss) are slight padding but nothing is redundant with structured data.

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 12-parameter nested mutation with no output schema, the description covers the full picture: precondition (draft only), mutation semantics, immutable fields, alternatives, return shape, workflow next step, and authentication. Nothing an agent needs in order 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 is 3, but the description adds real value the schema cannot express: that each supplied field replaces the stored value and that nested objects like `property` are replaced whole rather than merged. It also clarifies that `ground` and `entryPoint` cannot change.

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 (correct/complete) and resource (draft case), scopes it to updates only, and implicitly distinguishes itself from create_case and send_case_message. The title plus the description's 'only the fields to change' framing makes the operation unambiguous.

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 (a draft's facts need correcting, e.g. after evictions_validate_case reports gaps), the negative case (do not use on a submitted case), and the alternative for that case (evictions_send_case_message). Also routes to evictions_create_case when immutable fields must change.

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, but the description adds behavioral value beyond them: it discloses the return shape (each check's result with a failure reason, plus whether all passed) with no output schema present, and states the auth requirement (sign-in or API key). It does not cover edge behavior such as how many checks run or how large failure sets are returned.

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?

Four compact sentences with labeled slots (Input, Do not use, Next) and zero filler; the trigger condition is front-loaded and the alternatives trail it. Every clause carries routing or behavioral 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 one-parameter read-only validation tool with no output schema, the description covers the trigger, the input, the return semantics, the safety profile, the auth requirement, and the follow-up path. Nothing an agent needs in order 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?

Only one parameter, and schema coverage is 100% — the schema already documents the case_... id format and its origin tools. The description's 'Input: the case `id`' adds no meaning beyond that, 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?

States a specific verb and resource — runs the submission checks on a draft case — and explicitly differentiates from siblings by naming evictions_submit_case as the tool NOT to use. An agent can distinguish this from submit/update without opening schemas.

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 trigger ('when a draft looks complete, before asking the person to confirm'), an explicit exclusion ('Do not use this to submit'), and names the follow-up routing (update_case to fill a gap, then submit_case). Nothing 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?

Adds real behavioral context beyond the annotations: a live case with an engaged attorney goes on hold rather than being withdrawn immediately, a live key acts on a real case, and account auth (sign-in or API key) is required. It doesn't address re-invocation or reversibility of the withdrawal itself, which the annotations only hint at via destructiveHint/idempotentHint.

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 triggering condition, then inputs, then the hold/withdraw nuance, then the exclusion and the return shape. Every sentence carries distinct information with no restated boilerplate.

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, and the description compensates by describing the return value (the case, with state and nextAction indicating who it is waiting on). Auth requirements, the sibling to use instead, and the confirmation precondition are all covered for a destructive, open-world mutation.

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 workflow meaning by tying confirmedByPerson to the 'confirm with the person first' sequence rather than just restating the field name. It does not add format detail for id, which the schema already covers.

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 ('withdraw a case and stop it') and implicitly distinguishes itself from the read/update siblings by naming evictions_send_case_message as the wrong tool for messages. An agent can route to this tool without opening any 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?

Gives explicit when-to-use ('person has decided to withdraw a case'), explicit when-not ('Do not use this to report that the tenant has paid or to ask a question'), and names the alternative tool for that excluded case. It even specifies the precondition of confirming with the person before passing confirmedByPerson.

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