Skip to main content
Glama

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

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. On an update, send all of them again: this object replaces the one stored.
rentOwedCentsNoThe 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).
amountOwedCentsNoThe total the tenant owes now, in US cents (150000 is $1,500.00).
plaintiffContactNoHow the court reaches the plaintiff (owner or manager): a Texas petition states the address and telephone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / ledger / items / properties / kind
      Added 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"
      +}
    • changedInput schema / properties / property / properties / county / description
      Previous 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."
  2. Changed2 schema fields changed
    • addedInput schema / properties / lease / properties / noticeMethods
      Added 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"
      +}
    • addedInput schema / properties / priorNotice / properties / sealedEnvelope
      Added 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"
      +}
  3. Changed3 schema fields changed
    • addedInput schema / properties / lease / properties / monthToMonth
      Added value: +{
      +  "description": "For a holdover in Texas: whether the tenancy is month to month.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / lease / properties / noticePeriodDays
      Added 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"
      +}
    • addedInput schema / properties / lease / properties / terminationNoticeDate
      Added 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"
      +}
  4. Changed6 schema fields changed
    • changedInput schema / properties / attestations / description
      Previous 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."
    • addedInput schema / properties / attestations / properties / lateBeforeNoticeMonth
      Added 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"
      +}
    • addedInput schema / properties / parties / items / properties / phone
      Added value: +{
      +  "description": "The party’s telephone number, if known. A Texas petition states the tenant’s.",
      +  "maxLength": 40,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / plaintiffContact
      Added 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"
      +}
    • addedInput schema / properties / priorNotice / properties / type
      Added 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"
      +}
    • addedInput schema / properties / rentOwedCents
      Added 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"
      +}
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.