Skip to main content
Glama

Texas unequal-appraisal candidates (batch)

registry_tx_equity_candidates_batch
Read-onlyIdempotent

registry_tx_equity_candidates for many subjects in one call (1–50, e.g. a consultant's client parcels): each subject's id (your label, echoed back) and its urn, or county_fips and apn, plus the rule parameters once for every subject (area_band, year_band, min_matches, limit, tax_year). Each entry of results is that subject's answer from registry_tx_equity_candidates (subject, candidates, calc_args, selection, selection_rule, sources, warnings) or that subject's error (error, message, issues, and coverage on a miss), so one subject outside Texas, in Tarrant County, or not in the registry does not fail the others; the Texas-only and Tarrant checks apply to each subject. The selection rule and the notice appear once at the top (rule, notice) instead of in every answer; summary counts subjects, answered and errors. Candidates per subject only: this tool never runs calc_tx_unequal_appraisal and never picks comparables; a person decides, for each subject, which candidates (if any) to use, and only those go to calc_tx_unequal_appraisal (each subject's calc_args is its candidate list in that tool's input shape, for review and editing first). Relay each candidate's source rights from that subject's sources. For evidence calculations only: FactLot does not represent property owners, file protests, or advise whether to protest. Not an appraisal or an opinion of value (Tex. Occ. Code §1103.003(1)); not legal or tax advice and not a substitute for the advice of an attorney. Never returns owner names, mailing addresses, or ownership facts; do not look up the owners of candidate parcels. On the hosted API each answered subject counts as one registry lookup (a subject with an error is not counted). Requires a FactLot Registry (public-record facts about commercial property, each cited to the source file and record).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "subjects": "<subjects>"
    },
    "name": "registry_tx_equity_candidates_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum candidates returned (1–200).
subjectsYesThe subject parcels (1–50): each one's id and its urn, or county_fips and apn (with state_fips 48, or none).
tax_yearNoRoll year to compare in. Default: the newest tax year whose roll gives the subject a positive value.
area_bandNoImprovement area band as a share of the subject's (0.35: within ±35%).
year_bandNoYear-built band in years, applied when both the subject's and the candidate's are known.
min_matchesNoWiden from the neighborhood and ZIP code tiers to the whole county when they hold fewer than this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / subjects / items / properties / urn / description
      Previous value: -"FactLot parcel URN of the subject, e.g. fl:parcel:us-48201:0420150000012. Give this, or county_fips and apn."New value: +"FactLot parcel URN of the subject, e.g. fl:parcel:us-48201:0011440000001. Give this, or county_fips and apn."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnly/idempotent/non-destructive annotations, the description discloses partial-failure semantics (per-subject error object with error, message, issues, coverage), response deduplication (selection rule and notice appear once at the top with a summary of answered/errors), and metering ("each answered subject counts as one registry lookup (a subject with an error is not counted)"). It also states a hard data boundary — never returns owner names, mailing addresses, or ownership facts — which no annotation conveys.

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 batch purpose, input shape, and result shape, and every later sentence carries real information about errors, metering, or scope limits. It is a single dense paragraph with a long compliance tail ("not an appraisal or an opinion of value… not legal or tax advice"), which could be split or trimmed for scannability without losing meaning.

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?

There is no output schema, so the description carries the return burden itself and does so: it enumerates the per-subject answer fields, the per-subject error fields, and the top-level rule/notice/summary. For a 6-parameter batch tool with partial-failure behavior, nothing an agent needs to call it correctly or interpret results 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; the description earns above that by clarifying a semantic the schema cannot express — that the rule parameters (area_band, year_band, min_matches, limit, tax_year) are supplied once and apply across every subject, and that each subject's id is a caller label echoed back. It adds little on the individual field formats, since the schema already documents those.

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?

The first clause names the exact base tool and the batch variant ("registry_tx_equity_candidates for many subjects in one call (1–50)"), and immediately distinguishes the two by scale and use case (consultant's client parcels). An agent can identify this as the multi-subject form of a known sibling 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.

Usage Guidelines5/5

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

Explicit routing: "Candidates per subject only: this tool never runs calc_tx_unequal_appraisal and never picks comparables", plus the stated handoff ("only those go to calc_tx_unequal_appraisal"). It also states the batch-boundary conditions — Texas-only and Tarrant checks apply per subject, and one bad subject does not fail the others — which tells the agent when batching is safe versus when a single call is warranted.

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.