FactLot

Texas property tax protest deadlines (batch)

rules_tx_property_tax_protest_deadline_batch

Read-onlyIdempotent

Texas property tax protest deadlines for many notices in one call (1–200 items, e.g. a consultant's client list): each item's id, tax year and, if known, notice delivery date. Each result is exactly what rules_tx_property_tax_protest_deadline returns for that item under rule rules.tx.property_tax_protest_deadline@2 (deadline, unadjusted deadline, governing basis, conservative file-by date, skipped days, status, days_remaining, next_season, the item's warnings), echoed with its id; an item with invalid input carries its error and the others are still answered. One as_of (default: today in US Central time) applies to every item. summary counts the items per deadline, earliest first, with the earliest and latest deadline, and per status (by_status). The as_of used, the notes, the statute citations, the rule's verification status and the disclaimer appear once (value.as_of, value.notes, value.rule, value.disclaimer). A rules tool: never a registry lookup. Information about statutory deadlines: not legal or tax advice and not a substitute for the advice of an attorney; it does not say whether to protest. Verification status: verified. Cite rule rules.tx.property_tax_protest_deadline_batch@1 and its statutes.

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": {
      "items": "<items>"
    },
    "name": "rules_tx_property_tax_protest_deadline_batch"
  }
}

Input Schema

Name	Required	Description	Default
`as_of`	No	Date the status is measured from, YYYY-MM-DD. Default: the current date in US Central time (America/Chicago), when the call is answered; pass it to fix the date (for a report, or for El Paso and Hudspeth counties, which keep Mountain time). One date for every item.
`items`	Yes	The notices to compute deadlines for (1–200): each one's id, tax year and, if known, notice delivery date. Each result equals rules_tx_property_tax_protest_deadline for that item.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / as_of

Added value: +{
+  "description": "Date the status is measured from, YYYY-MM-DD. Default: the current date in US Central time (America/Chicago), when the call is answered; pass it to fix the date (for a report, or for El Paso and Hudspeth counties, which keep Mountain time). One date for every item.",
+  "format": "date",
+  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+  "type": "string"
+}

AddedNov 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only cover the read-only/idempotent/non-destructive profile, and the description goes well beyond: partial-failure semantics (an invalid item carries its error while others are still answered), a single as_of governing every item, what summary aggregates, and which fields are stated once (as_of, notes, rule, disclaimer). It also discloses verification status and the non-advice posture, which are behavioral facts an agent cannot infer from annotations.

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?

Purpose and batch size are front-loaded, then behavior, then output shape, then citations and disclaimer — a sensible order. The prose is dense and run-on in places, and some per-item field enumeration duplicates the schema, but no sentence is filler given the required disclaimer and citation language.

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 full return-value burden and does: per-item fields, the summary counts including per-status breakdown, and the batch-level value fields. For a two-parameter batch tool with partial-failure semantics, 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.

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented at the field level; the description largely restates the 1–200 item list and per-item fields. It adds minor meaning — 'one as_of applies to every item' and ids echoed back — but nothing about id uniqueness or date handling beyond the schema's own text.

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 — computing Texas property tax protest deadlines for many notices in one call — and ties itself to the singular sibling by promising each result equals rules_tx_property_tax_protest_deadline for that item. An agent can distinguish batch from single computation 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 Guidelines4/5

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

Gives clear use context ('many notices in one call, e.g. a consultant's client list') and the 1–200 item bound, which effectively routes single-notice cases to the singular tool, though it never says so explicitly. No explicit when-not guidance beyond the item bound.

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

All FactLot tools Inspect

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.