Tektolo Rental Property

Server Details

Priced make-ready estimates for US rental turnovers and security deposit settlement under each state's statute. Deterministic, with every rule cited.

Ownership verified

Status: Healthy
Last Tested: 2026-10-15 22:16
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-15 22:20 across 5 tools

Disambiguation4/5

The two deposit tools partition cleanly into lookup (rules) versus calculation (settle), and the taxonomy tool is clearly separate. The only real overlap is property_turnover_quick_estimate vs property_turnover_scope, which both price turnover work, but the descriptions explicitly route users (quick first, scope for rate cards/measured quantities).

Naming Consistency4/5

All names are snake_case with two strong, predictable domain prefixes (deposit_settlement_* and property_turnover_*). The trailing token varies in part of speech (verb 'settle' vs nouns 'rules', 'issue_codes', 'scope', 'quick_estimate'), a minor deviation from a strict verb_noun pattern but still readable and grouped.

Tool Count5/5

Five tools covering two tightly related sub-domains is well-scoped, with each tool earning its place (lookup, computation, taxonomy search, fast estimate, detailed scope). No redundancy or filler.

Completeness4/5

Both sub-domains have solid coverage: deposit rules plus a full settlement calculator, and turnover taxonomy plus quick and detailed estimates. Minor gaps exist, such as no tool to enumerate covered states/cities or to chain issue codes directly into an estimate, but core workflows are covered.

Available Tools

5 tools

deposit_settlement_rulesSecurity deposit rules for a state (and city)A

Read-onlyIdempotent

Inspect

Looks up the security deposit rules (deposits only) for one US state, with a covered city's deposit ordinance (Chicago, San Francisco, Berkeley, Los Angeles, Seattle, Portland, Minneapolis, Saint Paul). Inputs: state (two-letter code); optional city. Returns the deposit return deadline and what starts it, itemization and documentation duties, allowed deductions and depreciation, deposit interest, penalties, the deposit cap and recent changes, with citations. Not for: settling a specific move-out (deposit_settlement_settle does that), evictions, unpaid-rent collection, rent increases or rent control, lease renewal or notice periods, legal advice. Deterministic and source-cited: the same input gives the same result.

ParametersJSON Schema

Name	Required	Description
`city`	No	Optional city for its overlay (e.g. 'Chicago').
`as_of`	No	Optional date (YYYY-MM-DD): show the law in force on that day, for a past move-out the day the tenancy ended. Omitted: the current law.
`audit`	No	Also return the run record and input/result hashes (an audit trail). Default false.
`state`	Yes	US state, 2-letter code or name (e.g. 'TX').
`serve_pinned`	No	Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.
`expect_ruleset`	No	Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.

Output Schema

ParametersJSON Schema

Name	Required	Description
`run`	No
`links`	No
`result`	Yes
`signature`	No
`input_hash`	No
`client_refs`	No
`result_hash`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds behavior annotations do not carry: determinism ('same input gives the same result') and that results are source-cited. The versioned-ruleset refusal semantics live only in the schema, so the description leaves that behavioral nuance to the parameter docs rather than surfacing it.

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 purpose, then inputs, then returns, then exclusions — a sensible ordering. Slightly dense, but each sentence earns its place; the long 'Not for' list is high-value routing information rather than filler.

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 six-parameter tool with an output schema, the description covers purpose, input shape, the nature of the returned content (deadlines, itemization duties, deductions, interest, penalties, caps, citations), and explicit boundaries. Nothing an agent needs to select and call this correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema carries the parameter burden and the baseline is 3. The description names only state and city, omitting as_of, audit, serve_pinned, and expect_ruleset, so it adds essentially nothing beyond what the schema already documents in detail.

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 and resource (looks up security deposit rules for one state plus a covered city ordinance) and immediately scopes itself as 'deposits only'. It names the sibling it is not (deposit_settlement_settle) so an agent can route between the rules-lookup tool and the settlement-action tool 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.

Usage Guidelines5/5

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

Explicit exclusions are enumerated: settling a specific move-out (with the alternative named), evictions, unpaid-rent collection, rent increases, rent control, lease renewal, notice periods, and legal advice. This is exactly the when-not-to-use guidance that keeps an agent from mis-routing adjacent legal-adjacent questions.

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

deposit_settlement_settleSettle a security deposit after move-outA

Read-onlyIdempotent

Inspect

Settles a US residential security deposit after move-out under the state's statute (50 states and DC) and a covered city's ordinance. Inputs: state, deposit_usd, vacated_on; optional city, monthly_rent_usd, move_in_on, deductions (category, amount, item age, whether the tenant caused it), the dates that start a state's clock, and as_of. Returns the return deadline and its status, each deduction allowed or not (with depreciation), interest owed, refund due, penalty exposure, a draft itemized statement and a citation for every rule. Not for: legal advice, tenant demand letters, repair cost estimates, pet deposits, rentals outside the US. Deterministic and source-cited: the same input gives the same result.

ParametersJSON Schema

Name	Required	Description
`city`	No	City, for a city overlay where covered (e.g. 'Chicago'). Optional.
`as_of`	No	Today's date (YYYY-MM-DD) for the deadline status. Defaults to today (UTC); send it for repeatable results.
`audit`	No	Also return the run record and input/result hashes (an audit trail). Default false.
`state`	Yes	US state, 2-letter code (e.g. 'CA'); a state name also works.
`returned`	No	What the landlord has returned so far and when. With it, timeliness says whether the refund and the itemized statement were on time and how many days late.
`furnished`	No	The unit is rented furnished (California before AB 12: 3 months; Kansas: 1.5 months; Delaware: no cap).
`deductions`	No	What you intend to deduct (or, for a tenant, what the landlord listed). An explicit empty list means nothing is deducted (it decides the shorter no-deduction periods, e.g. Montana 10 days, Alaska 14); leave it out when that is not known yet.
`move_in_on`	No	Tenancy start (YYYY-MM-DD). Used for interest and, when an item's age is unknown, for depreciation.
`vacated_on`	Yes	Day the tenant moved out and returned possession (YYYY-MM-DD).
`client_refs`	No	Your own reference ids (e.g. unit_id, job_id). Echoed back, never used.
`deposit_usd`	Yes	Security deposit held, dollars.
`lease_end_on`	No	Day the lease was scheduled to end (YYYY-MM-DD), when it differs from when the tenancy actually ended (a broken lease). Lost rent and lease-break charges run to it; deadlines do not (they follow tenancy_ended_on, else the move-out, with the scheduled end as a later alternative).
`serve_pinned`	No	Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.
`tenancy_type`	No	written_lease or at_will (Maine 6033(2): a written agreement's period, at most 30 days, or 21 days for a tenancy at will; Massachusetts 15B(4): at will, 30 days after the move-out, a written lease, 30 days after its end). Left out with a move-out before tenancy_ended_on: the earlier (at-will) date leads and the other is listed.
`documentation`	No	What documentation you have; leave a field out when unknown.
`building_units`	No	Units in the building. Some interest rules depend on it (NY 6+, IL 25+).
`expect_ruleset`	No	Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.
`owner_occupied`	No	The landlord lives in the building (ME, NH, NJ and Chicago exempt small owner-occupied buildings; with building_units).
`small_landlord`	No	California AB 12 small landlord (a natural person or an LLC of natural persons owning at most two properties with at most four units; not for a service member): a two-month cap.
`pet_deposit_usd`	No	The part of deposit_usd that is a pet deposit (outside the cap in Missouri, Alabama, North Dakota and Saint Paul; allowed on top of it up to one month in Hawaii and Alaska, half a month in Kansas, a quarter in Nebraska).
`monthly_rent_usd`	No	Monthly rent, for the deposit cap check.
`prepaid_rent_usd`	No	Rent paid in advance beyond the first month, held besides deposit_usd. Counts toward the cap in AK, AZ, CA, CT, MD, MI and NY; earns interest in CT, MA (last month's rent), MD and Chicago; in Minneapolis it lowers the deposit cap to half a month.
`tenancy_ended_on`	No	When the tenancy actually ended (YYYY-MM-DD): the lease's end, or an earlier termination or accepted surrender. Deadlines that run from the end of the tenancy use it. For a tenant who left before the lease was due to end, send the scheduled end as lease_end_on (older callers sent it here, which still works: the deadline is then counted from it, with the move-out date as an earlier alternative where the facts point to one).
`tenant_abandoned`	No	The tenant abandoned the unit or was evicted (Maryland 8-203(h): the clock runs from the tenant's written demand; Washington 59.18.280: from when the landlord learns of it; Louisiana 9:3251(C): the one-month rule does not apply). Left out: inferred from tenant_gave_proper_notice: false; with a move-out before tenancy_ended_on the earlier abandonment clock leads and the other date is listed.
`contractor_needed`	No	Damage exceeds the deposit and needs a third-party contractor, and you said so in writing in time (Virginia, West Virginia: 15 more days).
`lease_return_days`	No	Return period the lease sets, in days, where the statute lets a lease set one (Colorado up to 60, Idaho up to 30, Maine shorter).
`lease_term_months`	No	Term of the lease in months (0 for month-to-month). Delaware's cap applies to leases of a year or more, New Mexico's to shorter ones.
`statement_sent_on`	No	Day you sent (or delivered) the itemized statement (YYYY-MM-DD). With it the statement is judged on time or late; documentation.itemized_statement alone cannot tell.
`demand_received_on`	No	Day you received the tenant's demand for the deposit (YYYY-MM-DD; written in Oklahoma, by first-class mail in Maryland 8-203(h)). Arizona, Kansas, Oklahoma, South Carolina and Mississippi start the clock on it.
`tenant_age_60_plus`	No	A person 60 or older occupies the unit (New Hampshire 540-A:5, I: the owner-occupied exemption does not reach the unit). tenant_age_62_plus true implies it.
`tenant_age_62_plus`	No	The tenant is 62 or older (Connecticut: a one-month cap).
`new_tenant_rent_usd`	No	Monthly rent the new tenant pays (with new_tenant_moved_in_on): the rent received for overlapping days is credited against rent claimed for them.
`third_party_managed`	No	A third party manages the unit or collects rent for a fee.
`claim_notice_sent_on`	No	Day you sent the written notice of intent to impose a claim on the deposit (YYYY-MM-DD). Florida (due within 30 days of termination) and the District of Columbia (within 45 days): the balance is due 30 days after it; a late notice does not count.
`deposit_collected_on`	No	Day the deposit was collected (YYYY-MM-DD); defaults to move_in_on. California (AB 12, from 2024-07-01) and Colorado caps depend on it.
`landlord_units_owned`	No	Rental units the landlord owns in all (Arkansas 5 or fewer, Georgia 10 or fewer, with third_party_managed, may be exempt).
`interest_paid_through`	No	Interest already paid or credited to the tenant up to this day (annual-payment rules: San Francisco, Los Angeles, Berkeley, Connecticut, Massachusetts, ...): interest is counted from it.
`interest_rate_percent`	No	Annual rate the deposit account paid, where the law sets interest at the bank's rate (New Jersey, North Dakota, New Hampshire, New York, Pennsylvania, Portland), or caps it (Massachusetts: 5% or the bank's lesser rate). Without it bank-rate interest is unknown. Illinois 765 ILCS 715 uses IDFPR's published rate instead.
`new_tenant_moved_in_on`	No	Day a new tenant moved in, if the unit was re-rented (YYYY-MM-DD). West Virginia and Wisconsin can end the period earlier; rent claimed for days from it on is not recoverable (re-rent mitigation).
`rent_ordinance_covered`	No	The unit is covered by the city's rent ordinance (Los Angeles RSO, Berkeley Rent Ordinance). Their deposit interest is owed only then; unknown: the amount is shown beside the refund, not in it.
`tenant_gave_proper_notice`	No	A termination notice that meets the statute was given (Alaska: 14 days instead of 30 when nothing is deducted for damage).
`lease_signed_or_renewed_on`	No	Day the current lease was signed or last renewed (YYYY-MM-DD). Georgia (2024-07-01) and Maryland (2024-10-01) caps apply to leases from then; defaults to move_in_on, with a warning that a later renewal may bring the new cap.
`nonstandard_provision_signed`	No	Wisconsin: the tenant signed a separate NONSTANDARD RENTAL PROVISIONS document covering the charge (ATCP 134.06(3)(b)); false makes such charges 'no'.
`forwarding_address_received_on`	No	Day you received the tenant's written forwarding address (YYYY-MM-DD). Several states start or hold the clock on it (Texas, Connecticut, Iowa, Minnesota).
`tenant_gave_forwarding_address`	No	False when the tenant never gave a forwarding address in writing (not just 'not yet known'). Illinois, Pennsylvania, Ohio, Delaware, South Carolina and New Hampshire then relieve the landlord of the penalty. Implied true by forwarding_address_received_on.

Output Schema

ParametersJSON Schema

Name	Required	Description
`run`	No
`links`	No
`result`	Yes
`signature`	No
`input_hash`	No
`client_refs`	No
`result_hash`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the description only needs to add beyond that. It does: determinism and source-citation ('the same input gives the same result'), plus a preview of what is produced (deadline status, per-deduction allow/deny with depreciation, interest owed, penalty exposure, draft itemized statement, citation per rule). It does not mention failure modes such as a ruleset-version mismatch, which live only in the schema.

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 purpose, then a compact inputs clause, an outputs clause, exclusions, and a determinism tag. It is dense and earns most of its length, though the inputs/outputs recap partially duplicates what the 100%-covered schema already states.

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

Completeness4/5

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

For a 45-parameter tool with nested objects, an output schema, and full annotation coverage, the description supplies the needed framing: scope, jurisdictional limits, output shape, and determinism. The remaining detail (per-field statutory nuance, ruleset pinning behavior) is fully carried by the schema, so nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter already carries authoritative documentation, including statutory citations and defaults. The description only recaps the required trio plus a grouped list of optional inputs, adding framing but no semantics the schema lacks; baseline 3 applies.

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

Purpose4/5

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

Opens with a specific verb and resource: settling a US residential security deposit after move-out under state statute and city ordinance, with the jurisdictional scope made explicit ('50 states and DC'). The 'Not for' list (legal advice, demand letters, repair cost estimates, pet deposits, non-US rentals) usefully walls off adjacent territory, though it never names a sibling tool, so an agent must still infer the split from deposit_settlement_rules and the property_turnover_* family.

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

Usage Guidelines4/5

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

Gives clear context for invocation (post-move-out deposit settlement, US only) and a concrete exclusion list that tells the agent what this tool is not for. It stops short of naming an alternative tool for the excluded cases, so the 'use X instead' half of the guidance 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.

property_turnover_issue_codesLook up turnover issue codesA

Read-onlyIdempotent

Inspect

Searches the standard taxonomy of rental-unit turnover issues (component.issue codes such as carpet.pet_urine). Inputs, all optional: query (keywords), area (e.g. flooring), limit (default 8). With no arguments it lists the taxonomy areas and the first codes. Returns matching codes with names and areas, and the total match count. Codes are optional: the turnover estimate tools also accept plain descriptions. Not for: cost estimates, legal or security-deposit questions, work other than rental turnover. Deterministic and source-cited: the same input gives the same result.

ParametersJSON Schema

Name	Required	Description
`area`	No	Optional taxonomy area filter, e.g. 'flooring' or 'walls' (not a room). Call with no arguments to list every area in `areas`.
`audit`	No	Also return the run record and input/result hashes (an audit trail). Default false.
`limit`	No	Most codes to return.
`query`	No	Keywords to match against codes, names and aliases, e.g. 'pet stain carpet'.
`client_refs`	No	Your own reference ids (e.g. unit_id, job_id). Echoed back, never used.
`serve_pinned`	No	Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.
`expect_ruleset`	No	Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.
`include_aliases`	No	Also return each code's aliases (larger result).

Output Schema

ParametersJSON Schema

Name	Required	Description
`run`	No
`links`	No
`result`	Yes
`signature`	No
`input_hash`	No
`client_refs`	No
`result_hash`	No

TDQS

A4.2/5.0

Behavior4/5

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 low. The description still adds value beyond them: determinism and source-citation ('same input gives the same result'), plus the returned shape (codes with names/areas and a total match count). It does not discuss the serve_pinned/expect_ruleset refusal behavior, which is only in the schema.

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?

Information is front-loaded: what it searches, then inputs, then no-arg behavior, then exclusions, then the determinism note. Dense but nearly every sentence carries routing or behavioral content; the 'Not for' list and the optional-codes remark are arguably a touch redundant with each other.

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?

With an output schema present, the description needn't explain return values, and annotations carry the safety profile. What remains - scope, no-arg fallback, exclusions, determinism - is fully covered, so an agent has everything needed to select and invoke the tool correctly.

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

Parameters3/5

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

Schema coverage is 100% and every parameter is documented in the schema itself, including defaults, bounds and the audit/client_refs/ruleset options. The description only restates query/area/limit and the 'all optional' fact, 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.

Purpose5/5

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

Opens with a specific verb and resource - searches the standard turnover-issue taxonomy - and gives a concrete code example (carpet.pet_urine), so the agent knows exactly what domain this covers. The 'Not for' clause and the note that the estimate tools accept plain descriptions separate it from property_turnover_quick_estimate/scope and the deposit_settlement siblings.

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

Usage Guidelines4/5

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

Explicitly states the no-argument behavior (lists areas and first codes), notes that codes are optional because estimate tools accept plain descriptions, and gives three exclusions (cost estimates, legal/security-deposit, non-turnover work). It stops short of naming a specific sibling tool to use instead, so routing is implied rather than spelled out.

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

property_turnover_quick_estimateQuick turnover estimate (start here)A

Read-onlyIdempotent

Inspect

Estimates what it costs to turn over a US rental unit after move-out; the first tool for a turnover estimate. Inputs: a 5-digit ZIP, bedrooms, bathrooms and the issues in plain English (e.g. "stained carpet in both bedrooms"), which may come from the user's photos; optional unit type, size, year built. Returns a priced make-ready estimate: repair tasks by trade with low/expected/high costs for the ZIP's labor market, must/should/could priorities, refer-outs to licensed professionals, assumptions, and links to the web tool and downloads. Same engine as property_turnover_scope. Not for: diagnosing hazards, legal advice on deposits, remodel bids, properties outside the US. Deterministic and source-cited: the same input gives the same result.

ParametersJSON Schema

Name	Required	Description	Default
`zip`	Yes	The user's 5-digit US ZIP code. If it is missing or not exactly 5 digits, ask the user; never guess, pad or correct it.
`audit`	No	Also return the run record and input/result hashes (an audit trail). Default false.
`sq_ft`	No	Interior sq ft.
`carpet`	No	Is there wall-to-wall carpet?
`detail`	No	summary (default, small) or full (every line).	summary
`issues`	No	What was found in plain English, e.g. ['stained carpet in both bedrooms', 'nail holes everywhere', 'oven is filthy']. Read like pasted notes: an entry may hold several conditions ('carpet stained, nail holes'; one finding each); a room before or after the condition sets the location ('Bedroom 2 carpet torn', 'mold in bathroom'); a written count sets the quantity ('3 blinds broken'); an entry saying there is no work ('no mold', 'leak fixed by tenant') is reported as not billed.
`profile`	No	minimum (rent-ready basics) \| standard \| premium (higher finish).	standard
`bedrooms`	Yes	0 for a studio.
`bathrooms`	Yes	Half baths count as 0.5.
`unit_type`	No	Single-family homes and townhomes get house-sized defaults (floor area, locks).	apartment
`price_tier`	No	bulk_contract (portfolio contract prices) \| pm_vendor (default: a property manager buying turns from local vendors) \| retail_one_off (an owner hiring one contractor).	pm_vendor
`year_built`	No	Drives lead-paint (pre-1978) handling.
`client_refs`	No	Your own reference ids (e.g. unit_id, job_id). Echoed back, never used.
`serve_pinned`	No	Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.
`expect_ruleset`	No	Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.

Output Schema

ParametersJSON Schema

Name	Required	Description
`run`	No
`links`	No
`result`	Yes
`signature`	No
`input_hash`	No
`client_refs`	No
`result_hash`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint true, destructiveHint false and openWorldHint false, so safety is covered. The description adds genuinely useful behavior beyond that: deterministic with source citations, the composition of the priced result (trades, low/expected/high, priorities, refer-outs), and that inputs may originate from user photos. It does not restate the safety profile, which is the right call.

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 purpose, then returns, then relationship to the sibling engine, then exclusions. It is dense but every clause carries information; the only cost is a long single-paragraph run of semicolon-separated ideas.

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 15-parameter tool with an output schema, the description covers what it returns, when to pick it over the sibling, the engine relationship, and the domain boundaries. Return-value detail is legitimately delegated to the output schema, so nothing an agent needs to call correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already carries per-parameter meaning (ZIP rules, issues parsing, profile, price_tier, ruleset pinning). The description only restates the input list at a high level and adds the 'plain English, maybe from photos' framing for issues, which is marginal over the schema. Baseline 3 is appropriate.

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?

Specific verb+resource ('Estimates what it costs to turn over a US rental unit after move-out') and it explicitly positions itself as the entry point. It distinguishes itself from siblings by naming property_turnover_scope ('Same engine as...') and by listing what it is not for, so an agent can route 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.

Usage Guidelines5/5

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

Says to start here ('the first tool for a turnover estimate'), names the alternative engine, and gives explicit exclusions: diagnosing hazards, legal advice on deposits, remodel bids, non-US properties. Both the when-to-use and when-not-to-use conditions are stated.

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

property_turnover_scopeScope a property turnoverA

Read-onlyIdempotent

Inspect

Turns move-out inspection findings for a US rental unit into a priced make-ready scope. For a first estimate use property_turnover_quick_estimate; use this one for rate cards, owner decisions or measured quantities. Inputs: property (ZIP, bedrooms, bathrooms; optional unit type, size, year built) and findings (a description or issue code, with location, extent and quantity); optional rate_card, decisions and detail. Returns tasks by trade with low/expected/high costs for the ZIP, priorities, vendor scopes, refer-outs to licensed professionals, assumptions, unknowns and download links. Not for: diagnosing hazards, legal advice on deposits, remodel bids, properties outside the US. Deterministic and source-cited: the same input gives the same result.

ParametersJSON Schema

Name	Required	Description	Default
`audit`	No	Also return the run record and input/result hashes (an audit trail). Default false.
`detail`	No	summary: totals, trade scopes, every line tied to a finding (capped at 40) plus the largest must-fix/refer-out lines, a one-line note on the routine lines left out, notes, and only findings needing attention (small). full: every line, finding and source.	summary
`retain`	No	Optional (contract 0.5.0). false: keep none of this request's text. By default the finding descriptions are kept with contact details and access codes removed, to improve matching; the estimate is the same either way.
`findings`	No	Move-out inspection findings, one per condition, with location and extent.
`property`	Yes	The unit: ZIP, size, type and year built.
`tax_rate`	No	Applied to all lines, e.g. 0.07.
`decisions`	No	Approve, decline or defer lines or findings from an earlier scope.
`rate_card`	No	Your own prices by trade or task; they replace the regional library prices.
`standards`	No	Finish profile, price tier and overrides.
`client_refs`	No	Your own reference ids (e.g. unit_id, job_id). Echoed back, never used.
`constraints`	No	Target ready date, whether the unit is occupied, access notes.
`serve_pinned`	No	Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.
`trade_vendors`	No	Vendor (name, contact) to put on each trade's lines.
`expect_ruleset`	No	Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.

Output Schema

ParametersJSON Schema

Name	Required	Description
`run`	No
`links`	No
`result`	Yes
`signature`	No
`input_hash`	No
`client_refs`	No
`result_hash`	No

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and side-effect profile is covered. The description adds genuinely new behavior: deterministic, source-cited results, refer-outs to licensed professionals, and assumptions/unknowns surfaced in the output. It stops short of discussing limits on input size (200 findings, 300 rate-card entries) which live only in the schema.

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 purpose and sibling routing, then inputs, returns, exclusions and a determinism note; each block earns its place. The final 'Deterministic and source-cited' sentence is slightly redundant with idempotentHint and could be folded into the returns sentence.

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?

With an output schema present, the description need not enumerate return fields, and it correctly summarizes them (tasks by trade, low/expected/high costs, priorities, vendor scopes, refer-outs, assumptions, unknowns, download links). Combined with rich annotations and complete schema coverage, 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.

Parameters4/5

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 goes modestly beyond by grouping the 14 flat parameters into a mental model (property vs. findings vs. optional rate_card/decisions/detail) and flagging which property fields are required vs. optional, which helps an agent plan a call.

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+output: turning move-out inspection findings for a US rental unit into a priced make-ready scope. It explicitly distinguishes itself from property_turnover_quick_estimate and names the conditions that select this tool, 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.

Usage Guidelines5/5

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

Explicit routing: 'For a first estimate use property_turnover_quick_estimate; use this one for rate cards, owner decisions or measured quantities.' It also lists exclusions under 'Not for' (hazard diagnosis, deposit legal advice, remodel bids, non-US properties). 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesOct 15, 2026

Changeddeposit_settlement_rules22 fields changed

addedInput schema / properties / as_of

Added value: +{
+  "description": "Optional date (YYYY-MM-DD): show the law in force on that day, for a past move-out the day the tenancy ended. Omitted: the current law.",
+  "format": "date",
+  "type": "string"
+}

addedInput schema / properties / expect_ruleset

Added value: +{
+  "description": "Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.",
+  "type": "string"
+}

addedInput schema / properties / serve_pinned

Added value: +{
+  "default": false,
+  "description": "Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.",
+  "type": "boolean"
+}

addedOutput schema / $defs / Alternative / properties / listed_if

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

removedOutput schema / $defs / CleaningRule / properties / effective_on

Removed value: -{
-  "anyOf": [
-    {
-      "format": "date",
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

addedOutput schema / $defs / DeductionRules / properties / cleaning / anyOf

Added value: +[
+  {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "amendment": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "from": {
+          "anyOf": [
+            {
+              "format": "date",
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "governed_by": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "note": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "source": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "until": {
+          "anyOf": [
+            {
+              "format": "date",
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "value": {
+          "$ref": "#/$defs/CleaningRule"
+        }
+      },
+      "required": [
+        "value"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "$ref": "#/$defs/CleaningRule"
+  },
+  {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "basis": {
+          "enum": [
+            "named",
+            "damage"
+          ],
+          "type": "string"
+        },
+        "condition": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "effective_on": {
+          "anyOf": [
+            {
+              "format": "date",
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "note": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "quote": {
+          "maxLength": 600,
+          "type": "string"
+        },
+        "routine": {
+          "default": "barred",
+          "enum": [
+            "barred",
+            "lease",
+            "reasonable"
+          ],
+          "type": "string"
+        },
+        "routine_signed_provision": {
+          "default": false,
+          "type": "boolean"
+        },
+        "section": {
+          "type": "string"
+        },
+        "source": {
+          "type": "string"
+        },
+        "unless_no_notice": {
+          "default": false,
+          "type": "boolean"
+        },
+        "verbatim": {
+          "default": true,
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "basis",
+        "section",
+        "quote",
+        "source"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+]

removedOutput schema / $defs / DeductionRules / properties / cleaning / items
```
Removed value: -{
-  "$ref": "#/$defs/CleaningRule"
-}
```
removedOutput schema / $defs / DeductionRules / properties / cleaning / type
```
Removed value: -"array"
```

addedOutput schema / $defs / DescribeEach

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "quote": {
+      "maxLength": 400,
+      "type": "string"
+    },
+    "rent_only_exempt": {
+      "default": false,
+      "type": "boolean"
+    },
+    "section": {
+      "type": "string"
+    },
+    "source": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "section",
+    "quote",
+    "source"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / InterestRule / properties / rate_schedule / anyOf

Added value: +[
+  {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "amendment": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "from": {
+          "anyOf": [
+            {
+              "format": "date",
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "governed_by": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "note": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "source": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "until": {
+          "anyOf": [
+            {
+              "format": "date",
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "value": {
+          "anyOf": [
+            {
+              "minimum": 0,
+              "type": "number"
+            },
+            {
+              "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$",
+              "type": "string"
+            }
+          ]
+        }
+      },
+      "required": [
+        "value"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "minimum": 0,
+    "type": "number"
+  },
+  {
+    "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$",
+    "type": "string"
+  },
+  {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "from": {
+          "format": "date",
+          "type": "string"
+        },
+        "note": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "rate_value": {
+          "anyOf": [
+            {
+              "minimum": 0,
+              "type": "number"
+            },
+            {
+              "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$",
+              "type": "string"
+            }
+          ]
+        },
+        "source": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "to": {
+          "format": "date",
+          "type": "string"
+        }
+      },
+      "required": [
+        "from",
+        "to",
+        "rate_value"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+]

removedOutput schema / $defs / InterestRule / properties / rate_schedule / items
```
Removed value: -{
-  "$ref": "#/$defs/RateWindow"
-}
```
removedOutput schema / $defs / InterestRule / properties / rate_schedule / type
```
Removed value: -"array"
```

addedOutput schema / $defs / Itemization / properties / describe_each

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/DescribeEach"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / $defs / MoveOutList / properties / unnotified_section

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / $defs / Provenance / properties / rules_as_of

Added value: +{
+  "anyOf": [
+    {
+      "format": "date",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

removedOutput schema / $defs / RateWindow

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "from": {
-      "format": "date",
-      "type": "string"
-    },
-    "note": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "rate_value": {
-      "anyOf": [
-        {
-          "minimum": 0,
-          "type": "number"
-        },
-        {
-          "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$",
-          "type": "string"
-        }
-      ]
-    },
-    "source": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "to": {
-      "format": "date",
-      "type": "string"
-    }
-  },
-  "required": [
-    "from",
-    "to",
-    "rate_value"
-  ],
-  "type": "object"
-}

addedOutput schema / $defs / Receipts / properties / estimate_note

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / $defs / Receipts / properties / estimate_section

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / $defs / ResultSignature

Added value: +{
+  "properties": {
+    "jws": {
+      "type": "string"
+    },
+    "payload": {
+      "$ref": "#/$defs/ResultSignaturePayload"
+    },
+    "verify_code": {
+      "type": "string"
+    },
+    "verify_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "jws",
+    "payload",
+    "verify_code",
+    "verify_url"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / ResultSignaturePayload

Added value: +{
+  "properties": {
+    "capability": {
+      "type": "string"
+    },
+    "engine_version": {
+      "type": "string"
+    },
+    "issued_at": {
+      "type": "string"
+    },
+    "kid": {
+      "type": "string"
+    },
+    "operation": {
+      "type": "string"
+    },
+    "result_hash": {
+      "type": "string"
+    },
+    "ruleset_hash": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "ruleset_version": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "v": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "v",
+    "kid",
+    "capability",
+    "operation",
+    "ruleset_version",
+    "ruleset_hash",
+    "engine_version",
+    "result_hash",
+    "issued_at"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / ReturnRule / properties / demand_in_writing
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```

addedOutput schema / properties / signature

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/ResultSignature"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changeddeposit_settlement_settle11 fields changed

changedInput schema / $defs / Deduction / properties / description / description

Previous value: -"Your own short note (e.g. 'bedroom carpet, pet stains'). Never stored, hashed or returned; the statement uses the category."New value: +"What was damaged or owed and the repair or charge (e.g. 'bedroom carpet: pet stains, two areas patched'). Printed under the line on the itemized statement you download (HTML or PDF); never stored, logged or hashed, and not in the result."

addedInput schema / $defs / Deduction / properties / good_faith_estimate

Added value: +{
+  "description": "The amount is a good-faith estimate: the repair cannot reasonably be finished within the return period, or the vendor's bills have not arrived (California 1950.5(h)(3)). The receipts then follow within 14 days of the repair or the documents.",
+  "type": "boolean"
+}

changedInput schema / properties / demand_received_on / description

Previous value: -"Day you received the tenant's written demand for the deposit (YYYY-MM-DD). Arizona, Kansas, Oklahoma, South Carolina and Mississippi start the clock on it."New value: +"Day you received the tenant's demand for the deposit (YYYY-MM-DD; written in Oklahoma, by first-class mail in Maryland 8-203(h)). Arizona, Kansas, Oklahoma, South Carolina and Mississippi start the clock on it."

addedInput schema / properties / expect_ruleset

Added value: +{
+  "description": "Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.",
+  "type": "string"
+}

addedInput schema / properties / serve_pinned

Added value: +{
+  "default": false,
+  "description": "Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.",
+  "type": "boolean"
+}

addedOutput schema / $defs / Deadline / properties / reverted_after

Added value: +{
+  "anyOf": [
+    {
+      "format": "date",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / $defs / Provenance / properties / rules_as_of

Added value: +{
+  "anyOf": [
+    {
+      "format": "date",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / $defs / ResultSignature

Added value: +{
+  "properties": {
+    "jws": {
+      "type": "string"
+    },
+    "payload": {
+      "$ref": "#/$defs/ResultSignaturePayload"
+    },
+    "verify_code": {
+      "type": "string"
+    },
+    "verify_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "jws",
+    "payload",
+    "verify_code",
+    "verify_url"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / ResultSignaturePayload

Added value: +{
+  "properties": {
+    "capability": {
+      "type": "string"
+    },
+    "engine_version": {
+      "type": "string"
+    },
+    "issued_at": {
+      "type": "string"
+    },
+    "kid": {
+      "type": "string"
+    },
+    "operation": {
+      "type": "string"
+    },
+    "result_hash": {
+      "type": "string"
+    },
+    "ruleset_hash": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "ruleset_version": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "v": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "v",
+    "kid",
+    "capability",
+    "operation",
+    "ruleset_version",
+    "ruleset_hash",
+    "engine_version",
+    "result_hash",
+    "issued_at"
+  ],
+  "type": "object"
+}

changedOutput schema / $defs / TimelyCheck / properties / status / enum

Previous value: -[
-  "on_time",
-  "late",
-  "not_yet_due",
-  "overdue",
-  "not_started",
-  "none_in_statute"
-]New value: +[
+  "on_time",
+  "late",
+  "not_yet_due",
+  "overdue",
+  "not_started",
+  "none_in_statute",
+  "reverted"
+]

addedOutput schema / properties / signature

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/ResultSignature"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedproperty_turnover_issue_codes5 fields changed

addedInput schema / properties / expect_ruleset

Added value: +{
+  "description": "Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.",
+  "type": "string"
+}

addedInput schema / properties / serve_pinned

Added value: +{
+  "default": false,
+  "description": "Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.",
+  "type": "boolean"
+}

addedOutput schema / $defs / ResultSignature

Added value: +{
+  "properties": {
+    "jws": {
+      "type": "string"
+    },
+    "payload": {
+      "$ref": "#/$defs/ResultSignaturePayload"
+    },
+    "verify_code": {
+      "type": "string"
+    },
+    "verify_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "jws",
+    "payload",
+    "verify_code",
+    "verify_url"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / ResultSignaturePayload

Added value: +{
+  "properties": {
+    "capability": {
+      "type": "string"
+    },
+    "engine_version": {
+      "type": "string"
+    },
+    "issued_at": {
+      "type": "string"
+    },
+    "kid": {
+      "type": "string"
+    },
+    "operation": {
+      "type": "string"
+    },
+    "result_hash": {
+      "type": "string"
+    },
+    "ruleset_hash": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "ruleset_version": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "v": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "v",
+    "kid",
+    "capability",
+    "operation",
+    "ruleset_version",
+    "ruleset_hash",
+    "engine_version",
+    "result_hash",
+    "issued_at"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / signature

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/ResultSignature"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedproperty_turnover_quick_estimate5 fields changed

addedInput schema / properties / expect_ruleset

Added value: +{
+  "description": "Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.",
+  "type": "string"
+}

addedInput schema / properties / serve_pinned

Added value: +{
+  "default": false,
+  "description": "Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.",
+  "type": "boolean"
+}

addedOutput schema / $defs / ResultSignature

Added value: +{
+  "properties": {
+    "jws": {
+      "type": "string"
+    },
+    "payload": {
+      "$ref": "#/$defs/ResultSignaturePayload"
+    },
+    "verify_code": {
+      "type": "string"
+    },
+    "verify_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "jws",
+    "payload",
+    "verify_code",
+    "verify_url"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / ResultSignaturePayload

Added value: +{
+  "properties": {
+    "capability": {
+      "type": "string"
+    },
+    "engine_version": {
+      "type": "string"
+    },
+    "issued_at": {
+      "type": "string"
+    },
+    "kid": {
+      "type": "string"
+    },
+    "operation": {
+      "type": "string"
+    },
+    "result_hash": {
+      "type": "string"
+    },
+    "ruleset_hash": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "ruleset_version": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "v": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "v",
+    "kid",
+    "capability",
+    "operation",
+    "ruleset_version",
+    "ruleset_hash",
+    "engine_version",
+    "result_hash",
+    "issued_at"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / signature

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/ResultSignature"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedproperty_turnover_scope5 fields changed

addedInput schema / properties / expect_ruleset

Added value: +{
+  "description": "Optional. The ruleset version you built against, as results carry it in provenance.ruleset_version (e.g. 'sd-2026.11.14'), or its sha256: hash. If the rules have changed since, the call fails (nothing computed, nothing charged) and says what is in force now, so you upgrade on your own schedule. Leave it out to answer under the current rules.",
+  "type": "string"
+}

addedInput schema / properties / serve_pinned

Added value: +{
+  "default": false,
+  "description": "Optional, with expect_ruleset. True asks us to answer under the ruleset version you named even when the rules have changed since, from that version's signed bundle; the result says so in served_from_bundle. We refuse a version older than 12 months, one a later correction or law change replaced for your state, or one we have no bundle for. Default false: the call fails whenever the rules have changed.",
+  "type": "boolean"
+}

addedOutput schema / $defs / ResultSignature

Added value: +{
+  "properties": {
+    "jws": {
+      "type": "string"
+    },
+    "payload": {
+      "$ref": "#/$defs/ResultSignaturePayload"
+    },
+    "verify_code": {
+      "type": "string"
+    },
+    "verify_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "jws",
+    "payload",
+    "verify_code",
+    "verify_url"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / ResultSignaturePayload

Added value: +{
+  "properties": {
+    "capability": {
+      "type": "string"
+    },
+    "engine_version": {
+      "type": "string"
+    },
+    "issued_at": {
+      "type": "string"
+    },
+    "kid": {
+      "type": "string"
+    },
+    "operation": {
+      "type": "string"
+    },
+    "result_hash": {
+      "type": "string"
+    },
+    "ruleset_hash": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "ruleset_version": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "v": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "v",
+    "kid",
+    "capability",
+    "operation",
+    "ruleset_version",
+    "ruleset_hash",
+    "engine_version",
+    "result_hash",
+    "issued_at"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / signature

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/ResultSignature"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

5 tool updatesOct 15, 2026
- First observeddeposit_settlement_rules
- First observeddeposit_settlement_settle
- First observedproperty_turnover_issue_codes
- First observedproperty_turnover_quick_estimate
- First observedproperty_turnover_scope

Publisher details

Operator: Tektolo · Publisher source
Operator website: https://www.tektolo.com · Publisher source
Vendor relationship: Not applicable
Documentation: https://tektolo.com/connect · Publisher source
Trust center: Not applicable
Restrictions: Not applicable

Related MCP Servers

Citesurf MCP
Marketing Search Monitoring
citesurf
A
license
A
quality
C
maintenance
Enables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.
Updated 6 months ago (2026-04-23 11:46 UTC)
16
11 npm
1
MIT
Competitor Monitor AI MCP
Marketing Research & Data AI & Machine Learning
CSOAI-ORG
A
license
C
quality
B
maintenance
Competitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 8 days ago (2026-10-08 01:01 UTC)
11
7 npm
54 PyPI
MIT
revnuvo-company-intelligence
Research & Data Monitoring Networking & Infrastructure
hardeyhemy
A
license
A
quality
C
maintenance
Revnuvo Company Intelligence tells AI agents what changed at a company, with evidence. It observes company websites, technologies, and DNS over time and returns timestamped, confidence-aware changes, signals, and monitoring.
Updated a month ago (2026-09-16 11:18 UTC)
9
MIT
industrylens-mcpofficial
Research & Data
IndustryLensOp
A
license
Not graded
quality
B
maintenance
Browse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.
Updated 2 months ago (2026-08-17 15:55 UTC)
MIT