Start and track a US eviction case in any state or DC; a licensed attorney reviews each real case.
Scored across 21 tools
Each tool targets a distinct resource and action, with descriptions explicitly steering away from alternatives (e.g., intake file vs. case document, get_case vs. get_case_events). Informational tools such as pricing, service overview, state facts, and jurisdiction resolution are clearly separated. There is no meaningful overlap that would cause misselection.
All tools use a consistent evictions_ prefix and snake_case verb_noun convention. Variations like evictions_get_payment_link and evictions_send_intake_file still follow the same predictable pattern. The naming is highly readable and uniform.
The 21 tools are slightly above the typical 3–15 range, but they map to a broad domain covering case lifecycle, documents, messages, charges, landlords, jurisdiction, and informational endpoints. Most tools appear purposeful, though a few read-only informational tools could potentially be consolidated. Overall the count is reasonable for the API's scope.
Core eviction case lifecycle operations are well covered: create, read, update, validate, submit, withdraw, add documents, message the team, list charges, and initiate payment. Minor gaps exist, such as no explicit document removal, draft deletion, or refund tool, but these are workable through existing tools or the web app. The surface is largely complete for the stated purpose.
Use this when the person asks you to add a document to a draft case: the lease, the tenant ledger, emails or messages with the tenant, proof that they own or manage the property, or a notice already served and its proof of service. Input: the case id, filename, purpose and contentBase64 (a PDF, JPEG or PNG of about 700 KB at most through this server; a file up to 4 MB goes through POST /v1/cases/{id}/documents with the person’s key). Adds the document to the case; each call adds one more, but a repeat with the same idempotencyKey is safe (it returns the first answer). Works on a draft; after a live case is submitted, only a document with the purpose other can be added. Returns the document as stored. Do not use this when no case exists yet (use evictions_send_intake_file) or to change the case’s facts (use evictions_update_case). Next: evictions_validate_case. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. | |
| purpose | Yes | What the document is: the lease, the tenant ledger, correspondence (emails or messages with the tenant), authority (proof the person owns or manages the property), prior_notice (a notice already served), prior_notice_proof (proof that notice was served), or other. | |
| filename | Yes | The file’s name, such as lease.pdf. Its type is read from the file itself, not from the name. | |
| contentBase64 | Yes | The file itself, base64-encoded: a PDF, JPEG or PNG of about 700 KB at most (950,000 base64 characters). A larger file, up to 4 MB, goes through the API directly. | |
| idempotencyKey | No | Sent as the Idempotency-Key header (printable ASCII, no spaces): a repeat of the same request with the same key returns the first answer instead of the document added twice. Always pass one, and reuse it if you repeat the call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: size ceiling (~700 KB via this server, 4 MB via the REST endpoint), draft-vs-submitted state rules (only purpose 'other' after submission), auth requirement (sign-in or API key), that each call appends rather than replaces, and that idempotencyKey makes repeats safe by returning the first answer. This is consistent with the annotations (readOnlyHint=false, idempotentHint=false), which describe side effects only in the default case.
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 behavior, then exclusions and next step. Slightly dense and repeats the size limit that the schema already encodes, but most sentences carry distinct 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?
No output schema exists, and the description covers the return ('the document as stored'), auth needs, file-type/size constraints, draft vs live state behavior, idempotency semantics, and routing to siblings. 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 coverage is 100%, so baseline is 3, but the description adds operative guidance the schema only hints at: the practical reason for the contentBase64 size cap and the instruction to 'always pass one, and reuse it if you repeat the call' for idempotencyKey. It restates the required inputs (id, filename, purpose, contentBase64) without adding much beyond the schema for those.
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 ('Add a document to a case') and immediately enumerates the concrete document types it accepts (lease, ledger, correspondence, authority, notices). It is clearly distinguishable from siblings like evictions_update_case or evictions_send_intake_file.
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 ('when the person asks you to add a document to a draft case'), explicit when-not ('Do not use this when no case exists yet (use evictions_send_intake_file) or to change the case's facts (use evictions_update_case)'), plus a next-step pointer to evictions_validate_case. Alternatives are named with the condition that selects them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this 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. Creates a draft case in the person’s account. Nothing is submitted. Add its documents with evictions_add_case_document. Pass an idempotencyKey and reuse it if you repeat the call, so a retry never makes a second case. For a property manager, landlordId (from evictions_list_landlords) names the owner the case is for and adds its saved management agreement to the case. Do not use this to change a case that already exists (use evictions_update_case). The result is the case, with state and nextAction (who it is waiting on and for what). Next: evictions_validate_case. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| lease | No | The lease, when there is one. | |
| ground | Yes | Why the case is brought: nonpayment of rent, a lease violation, or holdover (the tenant stayed after the lease ended). Cannot be changed later. | |
| ledger | No | Rent charges and payments, for a nonpayment case. | |
| parties | Yes | The plaintiff (the owner or manager) and each defendant (tenant). | |
| freeText | No | Anything else the attorney should know. | |
| property | Yes | The rental property and its owner of record. | |
| violation | No | For a lease violation case. | |
| entryPoint | Yes | Where the case starts: `notice` (a notice to the tenant comes first), or `filing` when a notice was already served (then give `priorNotice`). Cannot be changed later. | |
| landlordId | No | For a property manager: the id (lnd_...) of the landlord, the owner the case is for, from evictions_list_landlords. Its saved management agreement is added to the case as proof of authority. An archived landlord cannot be chosen, and a test-mode case cannot take one. | |
| priorNotice | No | The notice already served, for a case that starts at filing. | |
| attestations | Yes | The person’s own statements about the case. Ask the person for each one; never fill them in yourself. On an update, send all of them again: this object replaces the one stored. | |
| rentOwedCents | No | The unpaid rent alone, without late fees or other charges; 0 when no rent is owed. A court filing states it as the rent due, and rent claimed is never more, in US cents (150000 is $1,500.00). | |
| idempotencyKey | No | Sent as the Idempotency-Key header (printable ASCII, no spaces): a repeat of the same request with the same key returns the first answer instead of a second case. Always pass one, and reuse it if you repeat the call. | |
| amountOwedCents | No | The total the tenant owes now, in US cents (150000 is $1,500.00). | |
| plaintiffContact | No | How the court reaches the plaintiff (owner or manager): a Texas petition states the address and telephone. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that nothing is submitted (draft only), that an account/sign-in or API key is required, that 'ground' and 'entryPoint' are immutable, what the response contains ('the case, with state and nextAction'), and how the idempotencyKey makes retries safe. This is meaningful behavioral context that the readOnlyHint=false / destructiveHint=false annotations do 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?
The text is long but dense and front-loaded: eligibility, effect, idempotency, the landlord special case, the exclusion, the result shape and the next step each carry distinct information. Slightly more sentences than strictly needed, but none are 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?
For a 15-parameter nested mutation with no output schema and no annotations describing consequences, the description covers the essential gaps: what state the record lands in (draft, nothing submitted), auth requirements, immutability, retry safety, the landlord special case, and the returned fields. An agent has what it needs 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 baseline is 3, but the description adds real meaning for the trickiest parameter: landlordId names the owner the case is for and pulls in the saved management agreement, and idempotencyKey is explained as a reuse-on-retry mechanism. Remaining parameters are left to the already-thorough 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?
States a specific verb and resource ('Creates a draft case in the person's account') and immediately scopes it against siblings by saying what it does not do ('Do not use this to change a case that already exists (use evictions_update_case)'). An agent can distinguish it from evictions_update_case, evictions_add_case_document and evictions_validate_case 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?
Explicit when-to-use trigger ('when the person wants to start an eviction case and has given you its facts'), explicit exclusion with a named alternative, and an explicit next step ('Next: evictions_validate_case'). It even names the companion tool for follow-on work (evictions_add_case_document).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need one case in full: where it stands and what it is waiting on. Input: the case id. Returns its facts, deadlines, documents and, for a live case, the attorney once recorded. Do not use this to find a case whose id you do not have (use evictions_list_cases) or for its history (use evictions_get_case_events). The result is the case, with state and nextAction (who it is waiting on and for what). Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. |
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.
Use this when the person asks what has happened on a case so far. Input: the case id. Returns the events the person may see, oldest first, each with what happened, the state before and after, and when. Do not use this for where the case stands now (use evictions_get_case) or for messages (use evictions_list_case_messages). Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. |
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.
Use this when the person wants to pay a due charge on a case. Input: the case id and the chargeId from evictions_list_case_charges. Opens a hosted checkout for one due charge and returns its URL; asked again while that checkout is open, it returns the same URL. Give the URL to the person: paying is theirs to do, and no tool takes card details. Refused when the charge is not due or online payment is off. Do not use this to see whether a charge is paid (use evictions_list_case_charges). Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. | |
| chargeId | Yes | The id of a due charge on that case, from evictions_list_case_charges. |
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.
Use this when the person asks what a case costs or about refunds. Takes no input. Returns the platform fee, the costs that are separate from it and the refund rule, word for word as the pricing page says them, with its link. Do not use this for the charges already on a case (use evictions_list_case_charges). No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Use this when the person asks what Evictions API is, what is available today, how a real case is handled or who operates it. Takes no input. Returns the service’s description, its current status and who operates it, in the site’s own words, with links to the home and how-it-works pages. Do not use this for fees (use evictions_get_pricing) or for one state’s rules (use evictions_get_state_eviction_facts). No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Use this when the person has no account or key yet, or asks how to connect an agent. Takes no input. Returns the sign-up link, what test and live keys are, how this MCP server is reached and signed in to, and the links to the docs and the OpenAPI document. Do not use this to check a key the person already has: any tool that works with cases says so when its key is missing or refused. No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Use this when the person asks how eviction works in one state, such as the notice for nonpayment of rent or the court. Input: state, as a two-letter code, a name or a slug. Returns the page’s opening answer and only the facts published as verified and sourced for that state, each with its citation, source link, the date it was checked and a short quote of the cited text where there is one (a fact checked more than 90 days ago is left out), plus the state’s page and a notice that this is general information, not legal advice; a state with none says so. Do not use this for whether a case can be opened at an address (use evictions_resolve_jurisdiction) or for advice on a particular case. No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | A two-letter code (TX), a state name (Texas) or its slug (texas). DC is the District of Columbia. |
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.
Use this when the person asks what they owe on a case or whether a charge is paid. Input: the case id. Returns the charges on a case, oldest first, each with its id, kind, amount in cents and status (due, paid, void or refunded), and whether online payment is available. Do not use this for the published prices (use evictions_get_pricing). Next: evictions_get_payment_link for a due charge. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. |
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.
Use this when the person asks whether the Evictions API team has written about a case, or before writing to it. Input: the case id. Returns the messages on a case, the person’s own and the team’s, oldest first, each with its author, text and time. Do not use this for the case’s events (use evictions_get_case_events). Next: evictions_send_case_message to reply. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. |
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.
Use this when you need the person’s cases, or the id of a case you do not have. Input: optional limit and cursor, and landlordId for only one landlord’s cases (none for the cases with no landlord). Returns the cases of the key’s organization and mode (test or live), newest first, a page at a time, each with its state and nextAction, and nextCursor for the next page (null on the last). Do not use this when you already have the case id (use evictions_get_case). Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return, at most 100. The default is 20. | |
| cursor | No | `nextCursor` from the page before, for the next page. Leave it out for the first page. | |
| landlordId | No | Only the cases of this landlord (lnd_..., from evictions_list_landlords), or `none` for the cases with no landlord. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnly, idempotent, non-destructive behavior, the description adds substantial context beyond them: results are scoped to the key's organization and mode (test or live), ordered newest first, returned a page at a time, and include fields state, nextAction, and nextCursor (null on the last page). It also discloses the authentication requirement, which annotations do not cover.
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 use case and then proceeds through inputs, returns, exclusions, and prerequisites in a compact paragraph. Every sentence contributes necessary information (purpose, inputs, outputs, alternative, auth), with no repetition or 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?
For a paginated list tool with no output schema, the description fully explains return shape (state, nextAction, nextCursor), pagination semantics (nextCursor null on last page), ordering (newest first), scoping (organization and mode), and auth needs. 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 description coverage is 100%, so all three parameters are already fully documented in the schema. The description restates that limit and cursor are optional and that landlordId limits results to one landlord or 'none', adding marginal value over the schema. Baseline 3 is appropriate when the schema carries the semantic load.
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 uses a specific verb ('list') and resource ('cases'), states the scope (the person's cases, the key's organization and mode), and explicitly distinguishes itself from evictions_get_case. An agent can identify the tool's function and its primary sibling alternative 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 explicit when-to-use guidance ('when you need the person’s cases, or the id of a case you do not have') and when-not guidance ('Do not use this when you already have the case id (use evictions_get_case)'). It also names the required authentication context (sign-in or API key), leaving no ambiguity about usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person is a property manager and you need the owner a case is for, or to list one owner’s cases. Input: optional includeArchived. Returns the organization’s landlords (the owners it acts for, saved in the app), by name, each with its id, name, whether it is archived and how many cases in this mode name it; their contact details stay in the app. Live keys only: with a test key the list is always empty, since landlords are real owners, and a test case cannot take one. Do not use this to add or change a landlord (the person does that on the Landlords page of the app). Next: evictions_create_case with landlordId, or evictions_list_cases with landlordId. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| includeArchived | No | True to list archived landlords too. They keep their cases but cannot be chosen for a new one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses high-value behavioral traits: the list is always empty with a test key because landlords are real owners, contact details are not returned (they stay in the app), and archived landlords retain their cases but cannot be chosen for a new one. It also states the auth requirement (sign-in or API key). This is well past what the annotations 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?
The usage condition and scope are front-loaded, and most sentences carry distinct information. Slight redundancy in restating the optional input and the trailing auth sentence, but the density of useful detail justifies the length.
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 compensates by describing the returned shape (id, name, archived, case count) and explicitly noting what is withheld (contact details). Combined with the auth requirement, test-key caveat, exclusions, and next-step tools, an agent has everything needed to call and interpret this 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 optional parameter is fully documented in the schema, including the archived-retention semantics. The description only mentions 'Input: optional includeArchived' without adding meaning 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 ('List landlords' / 'Returns the organization's landlords (the owners it acts for, saved in the app)') and scopes it to the organization rather than all owners. It is clearly distinguishable from siblings like evictions_create_case and evictions_get_case, and it explicitly frames the tool as read-only enumeration.
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 condition ('when the person is a property manager and you need the owner a case is for, or to list one owner's cases'), an explicit when-not ('Do not use this to add or change a landlord'), and names the concrete follow-on tools (evictions_create_case with landlordId, evictions_list_cases with landlordId). 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.
Use this when you need every place the service covers, or the exact code or slug of a state. Takes no input. Returns the 50 states and DC, each with its two-letter code, name, slug and page on the site. Do not use this for one state’s eviction rules (use evictions_get_state_eviction_facts). No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Use this when you need to know, before creating a case, whether a case can be opened for a property’s location and which facts each ground of eviction needs there. Input: state, and county and city when known. Returns whether the jurisdiction is served and, for each ground, the facts a case needs, and with a test key also the notice rules of the fictional state ZZ. Do not use this for a state’s published facts with their sources (use evictions_get_state_eviction_facts, which needs no key). Next: evictions_create_case. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City of the property, when known. | |
| state | Yes | Two-letter state code, for example TX; DC for the District of Columbia. Test keys use the fictional state ZZ. | |
| county | No | County of the property, when known, as the US Census Bureau names it ("Henry County" or "Henry"). The answer names the court the place's rules say the case goes to (`court`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: it requires an account, it reports whether the jurisdiction is served, it returns per-ground fact requirements, and it exposes notice rules for the fictional state ZZ only under a test key. It stops short of noting rate limits or partial-result behavior, so it is strong but not exhaustive.
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 the trigger condition and then packs usage, exclusion, next tool, and auth into a short block with virtually no filler. The final sentences are somewhat run-on and mix routing with prerequisites, which costs a little readability.
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 carries the return-value burden and does so: jurisdiction service status, per-ground fact requirements, and ZZ notice rules with a test key. Combined with the auth note and the explicit next step, 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 baseline is 3. The description restates that state is the input and that county/city are supplied 'when known', but adds no format or synthesis detail (such as the county naming convention or the ZZ test-state convention) beyond what the schema fields already say.
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) plus the exact question it answers: whether a case can be opened for a property's location and which facts each eviction ground requires there. It explicitly differentiates itself from evictions_get_state_eviction_facts, so an agent can pick correctly 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 timing ('before creating a case'), a named alternative with its distinguishing property ('use evictions_get_state_eviction_facts, which needs no key'), the follow-up tool ('Next: evictions_create_case'), and the auth prerequisite (sign-in or API key). This is as complete a routing instruction as a tool description can carry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the person asks you to write to the Evictions API team about one of their live cases. Input: the case id and body. Sends the team a message about a live case, in the person’s name, and the team is told by email. Send only what the person asked to say. Each call sends one more message; a test case is refused, and an organization can send at most 20 every 10 minutes. Returns the message as stored. Do not use this to change a draft (use evictions_update_case). Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. | |
| body | Yes | The message, in the person’s words: only what they asked to say. |
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.
Use this when the person asks you to send a file (their lease, the tenant ledger, emails or messages with the tenant) to Evictions API before a case exists. Input: filename, contentBase64 (a PDF, JPEG or PNG of about 700 KB at most through this server; a file up to 4 MB goes through POST /v1/intake/files with the person’s key) and optionally purpose and a short note. The file waits in the person’s inbox, where they start a case from it. Needs a live key: with a test key, create a test case and use evictions_add_case_document. Returns the file’s id, its type, the purpose guessed for it and when it leaves the inbox if no case is started from it. Each call sends one more file, but a repeat with the same idempotencyKey is safe (it returns the first answer). Do not use this when the case already exists (use evictions_add_case_document), and do not create the case yourself: the person starts it from the inbox. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | A short note the person sees with the file, such as which property or tenant it is about. | |
| purpose | No | What the file is, if you know: the lease, the tenant ledger, correspondence (emails or messages with the tenant), or other. Left out, it is guessed from the file’s name, and the person can change it. | |
| filename | Yes | The file’s name, such as lease.pdf. Its type is read from the file itself, not from the name. | |
| contentBase64 | Yes | The file itself, base64-encoded: a PDF, JPEG or PNG of about 700 KB at most (950,000 base64 characters). A larger file, up to 4 MB, goes through the API directly. | |
| idempotencyKey | No | Sent as the Idempotency-Key header (printable ASCII, no spaces): a repeat of the same request with the same key returns the first answer instead of the file sent twice. Always pass one, and reuse it if you repeat the call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses the inbox lifecycle (file waits, person starts a case from it, expiration if none), the live-key requirement with a concrete fallback for test keys, the account/auth prerequisite, the 700 KB vs 4 MB transport limit, and the return payload. The note that each call sends one more file while a repeated idempotencyKey returns the first answer is consistent with idempotentHint=false (non-idempotent by default, opt-in safety via key), so this is additive context rather than a contradiction.
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 usage condition before mechanics, and every sentence carries information (alternatives, limits, auth, returns). It is dense and runs long, reading as a single block rather than clearly separated usage/behavior/return sections.
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 fields (id, type, guessed purpose, inbox expiry), and it covers auth, key type, size limits, and the sibling alternative. An agent has everything needed to call this correctly on the first try.
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 routing-relevant meaning: it names filename/contentBase64/purpose/note as the inputs, explains the size ceiling that forces the direct API path, and clarifies that purpose is optional and guessed. It repeats some schema text (enum values, max size), which caps this below 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?
States a specific verb and resource ('send a file to Evictions API before a case exists') and immediately scopes it against the sibling that does the same thing for existing cases. An agent can distinguish it from evictions_add_case_document and evictions_create_case 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 ('when the person asks you to send a file ... before a case exists'), explicit when-not-to-use ('Do not use this when the case already exists (use evictions_add_case_document)'), and a third routing rule for test keys ('create a test case and use evictions_add_case_document'). It also warns not to create the case itself. 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.
Use this when the person has said yes to submitting a draft that passes every check. Input: the case id and confirmedByPerson. A live case moves to submitted, its platform fee becomes a due charge, and a licensed attorney in the property’s state is engaged for it; nothing is served or filed until that attorney has reviewed it. With a test key the case is fictional and goes through a simulated review instead. With a live key this acts on a real case. Confirm with the person first, then pass confirmedByPerson: true. The case’s attestations must be the person’s own statements; never fill them in yourself. Do not use this to check a draft (use evictions_validate_case). Returns the case and its check results. Next: evictions_list_case_charges for the fee. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. | |
| confirmedByPerson | Yes | Set to true only after the person has said yes to this exact action on this case, in this conversation. |
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.
Use this when a draft’s facts need correcting or completing, for example after evictions_validate_case says what is missing. Input: the case id and only the fields to change; each one replaces the stored value, and an object such as property is replaced whole. Works only on a draft, and ground and entryPoint cannot change (create a new case instead). Do not use this on a submitted case (use evictions_send_case_message to tell the team what changed). The result is the case, with state and nextAction (who it is waiting on and for what). Next: evictions_validate_case. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. | |
| lease | No | The lease, when there is one. | |
| ground | No | Why the case is brought: nonpayment of rent, a lease violation, or holdover (the tenant stayed after the lease ended). Cannot be changed later. | |
| ledger | No | Rent charges and payments, for a nonpayment case. | |
| parties | No | The plaintiff (the owner or manager) and each defendant (tenant). | |
| freeText | No | Anything else the attorney should know. | |
| property | No | The rental property and its owner of record. | |
| violation | No | For a lease violation case. | |
| entryPoint | No | Where the case starts: `notice` (a notice to the tenant comes first), or `filing` when a notice was already served (then give `priorNotice`). Cannot be changed later. | |
| priorNotice | No | The notice already served, for a case that starts at filing. | |
| attestations | No | The person’s own statements about the case. Ask the person for each one; never fill them in yourself. On an update, send all of them again: this object replaces the one stored. | |
| rentOwedCents | No | The unpaid rent alone, without late fees or other charges; 0 when no rent is owed. A court filing states it as the rent due, and rent claimed is never more, in US cents (150000 is $1,500.00). | |
| amountOwedCents | No | The total the tenant owes now, in US cents (150000 is $1,500.00). | |
| plaintiffContact | No | How the court reaches the plaintiff (owner or manager): a Texas petition states the address and telephone. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover write/destructive/idempotent hints, and the description adds context they cannot: per-field replacement semantics including whole-object replacement of nested objects like `property`, draft-only scope, and the immutability of `ground` and `entryPoint`. It also states the auth requirement (sign-in or API key) and the returned shape (`state`, `nextAction`). No contradiction with destructiveHint=true or idempotentHint=true.
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 semantics, then constraints, exclusions, result and next step. Every sentence carries information, though the prose is dense and a few clauses (e.g. the parenthetical about create-a-new-case) could be tightened.
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 14-parameter mutation tool with nested objects and no output schema, the description covers scope, mutation semantics, immutable fields, authorization, exclusions and the return shape. Nothing an agent needs before invoking it 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 baseline is 3, but the description adds genuinely new semantics the schema does not state: this is a partial update where only supplied fields change, each replacing the stored value, and nested objects are replaced as a whole rather than merged. That is exactly the fact an agent needs to avoid silently wiping fields.
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 (changing a draft case) and immediately frames it against siblings: it references evictions_validate_case as the trigger, evictions_create_case as the alternative for immutable fields, and evictions_send_case_message for submitted cases. An agent can distinguish it from every other write tool in the family.
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 ('when a draft's facts need correcting or completing, for example after evictions_validate_case says what is missing'), explicit when-not-to-use ('Do not use this on a submitted case'), and a named alternative for that excluded case. Prescribes the follow-up call as well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a draft looks complete, before asking the person to confirm its submission. Input: the case id. Runs the submission checks on a draft and returns each check’s result, with the reason when it does not pass, and whether all passed. Changes nothing. Do not use this to submit (use evictions_submit_case). Next: evictions_update_case to fill a gap, or the person’s yes and then evictions_submit_case. Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. |
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.
Use this when the person has decided to withdraw a case and stop it. Input: the case id and confirmedByPerson. A live case with an attorney already engaged goes on hold instead and is withdrawn once the attorney has confirmed that all work has stopped. With a live key this acts on a real case. Confirm with the person first, then pass confirmedByPerson: true. Do not use this to report that the tenant has paid or to ask a question (use evictions_send_case_message). The result is the case, with state and nextAction (who it is waiting on and for what). Needs the person’s account: sign-in or an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The case id (case_...), as returned by evictions_create_case or evictions_list_cases. | |
| confirmedByPerson | Yes | Set to true only after the person has said yes to this exact action on this case, in this conversation. |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
evictions_create_case1 field changedInput schema / properties / landlordIdAdded value: +{
+ "description": "For a property manager: the id (lnd_...) of the landlord, the owner the case is for, from evictions_list_landlords. Its saved management agreement is added to the case as proof of authority. An archived landlord cannot be chosen, and a test-mode case cannot take one.",
+ "pattern": "^[A-Za-z0-9_-]{1,100}$",
+ "type": "string"
+}evictions_list_cases1 field changedInput schema / properties / landlordIdAdded value: +{
+ "description": "Only the cases of this landlord (lnd_..., from evictions_list_landlords), or `none` for the cases with no landlord.",
+ "pattern": "^[A-Za-z0-9_-]{1,100}$",
+ "type": "string"
+}evictions_list_landlordsevictions_create_case2 fields changedInput schema / properties / ledger / items / properties / kindAdded value: +{
+ "description": "For a charge only: what it is for. `other_fee` for any other charge; `eviction_fee`, `attorney_fee` or `court_cost` for a cost of the eviction itself, which no notice demands.",
+ "enum": [
+ "rent",
+ "late_fee",
+ "utilities",
+ "other_fee",
+ "eviction_fee",
+ "attorney_fee",
+ "court_cost"
+ ],
+ "type": "string"
+}Input schema / properties / property / properties / county / descriptionPrevious value: -"County, when known."New value: +"County, when known, as the US Census Bureau names it (\"Henry County\" or \"Henry\"); one the state does not have is refused."evictions_resolve_jurisdiction1 field changedInput schema / properties / county / descriptionPrevious value: -"County of the property, when known."New value: +"County of the property, when known, as the US Census Bureau names it (\"Henry County\" or \"Henry\"). The answer names the court the place's rules say the case goes to (`court`)."evictions_update_case2 fields changedInput schema / properties / ledger / items / properties / kindAdded value: +{
+ "description": "For a charge only: what it is for. `other_fee` for any other charge; `eviction_fee`, `attorney_fee` or `court_cost` for a cost of the eviction itself, which no notice demands.",
+ "enum": [
+ "rent",
+ "late_fee",
+ "utilities",
+ "other_fee",
+ "eviction_fee",
+ "attorney_fee",
+ "court_cost"
+ ],
+ "type": "string"
+}Input schema / properties / property / properties / county / descriptionPrevious value: -"County, when known."New value: +"County, when known, as the US Census Bureau names it (\"Henry County\" or \"Henry\"); one the state does not have is refused."evictions_create_case2 fields changedInput schema / properties / lease / properties / noticeMethodsAdded value: +{
+ "description": "In Georgia: the additional ways the rental agreement says a notice must be delivered, exactly as the lease states them, or the word `none`. The notice is posted on the door and states these methods too.",
+ "maxLength": 500,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / priorNotice / properties / sealedEnvelopeAdded value: +{
+ "description": "In Georgia: whether the notice was posted in a sealed envelope on the door of the premises, as the person states it. The filing says so; a posted notice answered false there does not pass the prior-notice check.",
+ "type": "boolean"
+}evictions_update_case2 fields changedInput schema / properties / lease / properties / noticeMethodsAdded value: +{
+ "description": "In Georgia: the additional ways the rental agreement says a notice must be delivered, exactly as the lease states them, or the word `none`. The notice is posted on the door and states these methods too.",
+ "maxLength": 500,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / priorNotice / properties / sealedEnvelopeAdded value: +{
+ "description": "In Georgia: whether the notice was posted in a sealed envelope on the door of the premises, as the person states it. The filing says so; a posted notice answered false there does not pass the prior-notice check.",
+ "type": "boolean"
+}evictions_add_case_documentevictions_send_intake_fileevictions_create_case3 fields changedInput schema / properties / lease / properties / monthToMonthAdded value: +{
+ "description": "For a holdover in Texas: whether the tenancy is month to month.",
+ "type": "boolean"
+}Input schema / properties / lease / properties / noticePeriodDaysAdded value: +{
+ "description": "In Texas: the notice period, in days, the written lease sets for this notice; 3 when the lease sets none.",
+ "maximum": 365,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / lease / properties / terminationNoticeDateAdded value: +{
+ "description": "For a month-to-month holdover in Texas: the day written notice ending the tenancy was given, as YYYY-MM-DD.",
+ "type": "string"
+}evictions_update_case3 fields changedInput schema / properties / lease / properties / monthToMonthAdded value: +{
+ "description": "For a holdover in Texas: whether the tenancy is month to month.",
+ "type": "boolean"
+}Input schema / properties / lease / properties / noticePeriodDaysAdded value: +{
+ "description": "In Texas: the notice period, in days, the written lease sets for this notice; 3 when the lease sets none.",
+ "maximum": 365,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / lease / properties / terminationNoticeDateAdded value: +{
+ "description": "For a month-to-month holdover in Texas: the day written notice ending the tenancy was given, as YYYY-MM-DD.",
+ "type": "string"
+}evictions_create_case6 fields changedInput schema / properties / attestations / descriptionPrevious value: -"The person’s own statements about the case. Ask the person for each one; never fill them in yourself."New value: +"The person’s own statements about the case. Ask the person for each one; never fill them in yourself. On an update, send all of them again: this object replaces the one stored."Input schema / properties / attestations / properties / lateBeforeNoticeMonthAdded value: +{
+ "description": "For nonpayment: whether the tenant was late or behind on rent before the month the notice was given. A Texas petition states it.",
+ "type": "boolean"
+}Input schema / properties / parties / items / properties / phoneAdded value: +{
+ "description": "The party’s telephone number, if known. A Texas petition states the tenant’s.",
+ "maxLength": 40,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / plaintiffContactAdded value: +{
+ "description": "How the court reaches the plaintiff (owner or manager): a Texas petition states the address and telephone.",
+ "properties": {
+ "address": {
+ "description": "The plaintiff’s mailing address, on one line.",
+ "maxLength": 500,
+ "minLength": 1,
+ "type": "string"
+ },
+ "email": {
+ "description": "The plaintiff’s email address, if they want it on the filing.",
+ "format": "email",
+ "maxLength": 254,
+ "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+ "type": "string"
+ },
+ "phone": {
+ "description": "The plaintiff’s telephone number.",
+ "maxLength": 40,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "address",
+ "phone"
+ ],
+ "type": "object"
+}Input schema / properties / priorNotice / properties / typeAdded value: +{
+ "description": "Which notice it was, as written on it: a notice to vacate, a notice to pay rent or vacate, pay or quit, or cure or quit.",
+ "enum": [
+ "notice_to_vacate",
+ "notice_to_pay_rent_or_vacate",
+ "pay_or_quit",
+ "cure_or_quit"
+ ],
+ "type": "string"
+}Input schema / properties / rentOwedCentsAdded value: +{
+ "description": "The unpaid rent alone, without late fees or other charges; 0 when no rent is owed. A court filing states it as the rent due, and rent claimed is never more, in US cents (150000 is $1,500.00).",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}evictions_update_case6 fields changedInput schema / properties / attestations / descriptionPrevious value: -"The person’s own statements about the case. Ask the person for each one; never fill them in yourself."New value: +"The person’s own statements about the case. Ask the person for each one; never fill them in yourself. On an update, send all of them again: this object replaces the one stored."Input schema / properties / attestations / properties / lateBeforeNoticeMonthAdded value: +{
+ "description": "For nonpayment: whether the tenant was late or behind on rent before the month the notice was given. A Texas petition states it.",
+ "type": "boolean"
+}Input schema / properties / parties / items / properties / phoneAdded value: +{
+ "description": "The party’s telephone number, if known. A Texas petition states the tenant’s.",
+ "maxLength": 40,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / plaintiffContactAdded value: +{
+ "description": "How the court reaches the plaintiff (owner or manager): a Texas petition states the address and telephone.",
+ "properties": {
+ "address": {
+ "description": "The plaintiff’s mailing address, on one line.",
+ "maxLength": 500,
+ "minLength": 1,
+ "type": "string"
+ },
+ "email": {
+ "description": "The plaintiff’s email address, if they want it on the filing.",
+ "format": "email",
+ "maxLength": 254,
+ "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+ "type": "string"
+ },
+ "phone": {
+ "description": "The plaintiff’s telephone number.",
+ "maxLength": 40,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "address",
+ "phone"
+ ],
+ "type": "object"
+}Input schema / properties / priorNotice / properties / typeAdded value: +{
+ "description": "Which notice it was, as written on it: a notice to vacate, a notice to pay rent or vacate, pay or quit, or cure or quit.",
+ "enum": [
+ "notice_to_vacate",
+ "notice_to_pay_rent_or_vacate",
+ "pay_or_quit",
+ "cure_or_quit"
+ ],
+ "type": "string"
+}Input schema / properties / rentOwedCentsAdded value: +{
+ "description": "The unpaid rent alone, without late fees or other charges; 0 when no rent is owed. A court filing states it as the rent due, and rent claimed is never more, in US cents (150000 is $1,500.00).",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}evictions_create_caseevictions_get_caseevictions_get_case_eventsevictions_get_payment_linkevictions_get_pricingevictions_get_service_overviewevictions_get_startedevictions_get_state_eviction_factsevictions_list_case_chargesevictions_list_case_messagesevictions_list_casesevictions_list_statesevictions_resolve_jurisdictionevictions_send_case_messageevictions_submit_caseevictions_update_caseevictions_validate_caseevictions_withdraw_caseCourt e-filing and process serving. Submit filings, serve process, and manage orders.
Find, compare and price licensed U.S. lawyers from official licensing records. Not legal advice.
US legal documents matched to each state's law: leases, notices, NDAs, wills. PDF or Word.
Check US leases for red flags and look up verified state tenant law with statute citations.
Add one secure layer between your agents and this server.
