Skip to main content
Glama

Evictions API

by io.github.evictionsapi
OverviewDiscussionsAdmin

Change a draft case

evictions_update_case
DestructiveIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe case id (case_...), as returned by evictions_create_case or evictions_list_cases.
leaseNoThe lease, when there is one.
groundNoWhy the case is brought: nonpayment of rent, a lease violation, or holdover (the tenant stayed after the lease ended). Cannot be changed later.
ledgerNoRent charges and payments, for a nonpayment case.
partiesNoThe plaintiff (the owner or manager) and each defendant (tenant).
freeTextNoAnything else the attorney should know.
propertyNoThe rental property and its owner of record.
violationNoFor a lease violation case.
entryPointNoWhere 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.
priorNoticeNoThe notice already served, for a case that starts at filing.
attestationsNoThe person’s own statements about the case. Ask the person for each one; never fill them in yourself.
amountOwedCentsNoThe total the tenant owes now, in US cents (150000 is $1,500.00).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the crucial PATCH semantics ('each one replaces the stored value', whole objects replaced), the draft-only restriction (annotations don't say this), which fields are immutable, the auth requirement, and the returned `state`/`nextAction`. This is substantial context the structured fields do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the when-to-use condition, then input semantics, constraints, result, next step and auth. Dense and well ordered; a couple of clauses (the parenthetical next-action gloss) are slight padding but nothing is redundant with structured data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter nested mutation with no output schema, the description covers the full picture: precondition (draft only), mutation semantics, immutable fields, alternatives, return shape, workflow next step, and authentication. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real value the schema cannot express: that each supplied field replaces the stored value and that nested objects like `property` are replaced whole rather than merged. It also clarifies that `ground` and `entryPoint` cannot change.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (correct/complete) and resource (draft case), scopes it to updates only, and implicitly distinguishes itself from create_case and send_case_message. The title plus the description's 'only the fields to change' framing makes the operation unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the trigger (a draft's facts need correcting, e.g. after evictions_validate_case reports gaps), the negative case (do not use on a submitted case), and the alternative for that case (evictions_send_case_message). Also routes to evictions_create_case when immutable fields must change.

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

All Evictions API toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources