Skip to main content
Glama
Capital-W-Holdings

DFX Real Estate Intelligence

Find parcels by place, use, tenure, vintage and assessed value

search_parcels
Read-onlyIdempotent

Search assessor parcel records using filters such as state, municipality, land use, owner-occupancy, tax exemption, year built, and assessed value ranges, returning property details and match counts.

Instructions

Search the assessor parcel layer with filters instead of one exact address. Filter by state, municipality, assessor land use code, owner-occupancy, tax-exempt status, year built and assessed value range; results carry assessed value, gross building area, assessed value per square foot, the annual tax and the year built. This is the only way to ask a QUESTION of the parcel layer: resolve_address needs an address you already have. Every answer states the true match count alongside the sample, and a search that matches nothing names the filter that emptied it rather than returning a bare empty list. At least one filter is required. Free.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax 50. This sizes the SAMPLE only: every answer states the true match count beside it, so a small limit never hides how big the result really is.
stateNoTwo letter state code
land_useNoAssessor land use code, for example 'R3' for a three family dwelling
tax_exemptNotrue for the institutional universe (churches, universities, authorities), false for the taxable one
built_afterNoExclusive lower bound on year built
built_beforeNoExclusive upper bound on year built
max_assessedNoMaximum assessed total, in dollars
min_assessedNoMinimum assessed total, in dollars
municipalityNoCity or town, for example 'Boston'
owner_occupiedNotrue for owner-occupied, false for investor or institutionally held. Parcels whose roll does not state it are excluded either way.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds key behavioral details: every answer includes the true match count alongside the sample, and a match-nothing search names the filter that emptied it. It also lists the output fields (assessed value, gross building area, etc.).

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

Conciseness3/5

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

The description is somewhat verbose and redundant, e.g., 'instead of one exact address' and later 'resolve_address needs an address you already have' convey the same idea. The trailing 'Free.' adds noise. It could be more concise while retaining the key points.

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 tool with 10 parameters and no output schema, the description covers essential context: it states that results carry specific fields, explains the sample/true-match-count behavior, and notes the empty-result behavior. Missing details like pagination or output structure are not critical given the absence of an output schema.

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?

The schema already provides per-parameter descriptions at 100% coverage. The tool description summarizes the filter types (state, municipality, land use, owner-occupancy, tax-exempt, year built, assessed value) but does not significantly extend the schema details. However, it reinforces the purpose of each filter group, which is helpful.

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 description clearly states the tool searches the assessor parcel layer with filters, using the verb 'Search' and specifying the resource. It explicitly contrasts with resolve_address ('instead of one exact address'), making the primary use case unambiguous.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool (for filter-based queries) versus resolve_address (which needs an exact address), and notes that at least one filter is required. It also clarifies that the 'limit' parameter only sizes the sample, not the true result set.

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