Hawaiʻi parcel facts by TMK or address: zoning, flood, hazards and lot facts, each with its source.
Scored across 4 tools
get_clip and search_lots are clearly distinct, but get_parcel and get_listing_facts overlap heavily: both accept TMK/address and return sourced lot facts. The listing-oriented framing of get_listing_facts helps somewhat, but an agent could still reasonably choose the wrong one when asked for lot information.
All names are snake_case and follow a predictable verb_resource pattern: get_clip, get_listing_facts, get_parcel, search_lots. The use of both get_ and search_ is natural for retrieval versus discovery, so this is mostly consistent.
Four tools are well within a sensible scope for a focused parcel-data server. Each maps to a distinct capability: single-parcel facts, listing-oriented facts, nearby-lot search, and a 3D clip.
The surface covers parcel lookup, filtered search, listing fact-checking, and visual output, which is strong for a read-only data product. A few plausible workflow gaps remain, such as bulk parcel lookup or explicit source/permalink retrieval, but core needs appear covered.
Use this when someone wants a short 3D video (MP4) of one Hawaiʻi lot by TMK, drawn from public lidar with the lot line on the ground.
| Name | Required | Description | Default |
|---|---|---|---|
| tmk | No | Hawaiʻi Tax Map Key, 9 digits, dashes optional, e.g. 4-4-2-016-063 | |
| address | No | Or a Hawaiʻi street address, e.g. 4-1345 Kuhio Hwy, Kapaa |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the source is public lidar, the lot line is rendered on the ground, and the deliverable is an MP4. It does not disclose generation latency, cost, or async delivery, which matters for a video-rendering tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence opening with "Use this when" — the trigger condition comes first and every clause (format, scope, key, source) carries information. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose, input key, data source, and output format are all covered, and annotations handle the safety profile. With no output schema, the one unresolved point is how the MP4 is delivered (URL, file, job id), which the description leaves implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear examples for both tmk and address, so the schema carries the semantics. The description reinforces TMK as the lookup key but never mentions that an address is an accepted alternative, adding only marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource: producing a 'short 3D video (MP4) of one Hawaiʻi lot by TMK' from public lidar. This clearly disambiguates the otherwise opaque name 'get_clip' from data-retrieval siblings like get_parcel and get_listing_facts, though no sibling is named directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when someone wants a short 3D video (MP4) of one Hawaiʻi lot" gives a concrete triggering intent. It omits any when-not guidance or alternative routing (e.g., use get_parcel for facts only), so it stops short of full 5-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when an agent is writing or checking a Hawaiʻi listing and needs the lot facts with their sources, by TMK or street address. It writes nothing itself.
| Name | Required | Description | Default |
|---|---|---|---|
| tmk | No | Hawaiʻi Tax Map Key, 9 digits, dashes optional, e.g. 4-4-2-016-063 | |
| address | No | Or a Hawaiʻi street address, e.g. 4-1345 Kuhio Hwy, Kapaa |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
"It writes nothing itself" restates the readOnlyHint/destructiveHint=false annotations and adds no new information. The one genuinely additive phrase is "with their sources," which tells the agent the response carries citations — useful since there is no output schema. Nothing is said about ambiguous-address resolution, error behavior, or result limits for an openWorldHint tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the usage trigger comes first, the retrieval mode second, and the safety note closes it. No filler, no restatement of the title, nothing that could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with no required arguments and no output schema, the description covers the trigger, the lookup keys, and the nature of the return (facts plus sources). It stops short of explaining behavior when an address matches multiple lots or is not found, which matters because no parameter is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both properties carry format examples (9-digit TMK, sample street address), so the baseline of 3 applies. The description's "by TMK or street address" echoes the schema's own 'Or a Hawaiʻi street address' wording rather than adding new semantics about the either/or choice or what happens if both or neither are supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (lot facts with their sources) and the two lookup keys (TMK or street address), so an agent knows exactly what it retrieves. It does not differentiate itself from the sibling get_parcel, which is the most likely source of confusion given the near-identical domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when an agent is writing or checking a Hawaiʻi listing" gives a concrete triggering context rather than a generic 'get data' framing. It offers no when-not conditions and never names an alternative among get_parcel, get_clip, or search_lots, so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks about one Hawaiʻi lot by TMK or street address: zoning and its dimensional rules, State Land Use District, flood zone, Special Management Area, tsunami and sea level rise, lava zone and slope, each with its source. Answers questions about one Hawaiʻi lot, by TMK or street address: what is this parcel zoned and what are the dimensional rules (setbacks, height, lot coverage, density), what the county code lists for adding to the lot (an ADU or a second dwelling), is it in the Special Management Area (SMA), which State Land Use District (Urban, Rural, Agricultural, Conservation), what FEMA flood zone, is it in the tsunami evacuation zone, the 3.2 ft sea level rise flood zone or the Sea Level Rise Constraint District, the wildfire risk, the lava flow hazard zone on Hawaiʻi Island, elevation, slope and aspect, Important Agricultural Lands, soil series and farmland rating, wetlands and streams, historic properties nearby, nearest wells and depth to water, water and sewer service and cesspool records, landslide and dam zones, shoreline setback and vacation rental (TVR) standing on Kauaʻi, tax class and acres. One call returns every finding for the lot, each with its official county, State or federal source, and a permalink to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| tmk | No | Hawaiʻi Tax Map Key, 9 digits, dashes optional, e.g. 4-4-2-016-063 | |
| address | No | Or a Hawaiʻi street address, e.g. 4-1345 Kuhio Hwy, Kapaa |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description usefully adds that one call returns every finding 'each with its official county, State or federal source, and a permalink to cite', which is real behavioral value beyond the annotations. It does not address failure modes (unknown TMK, ambiguous address) or rate/latency characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The usage trigger is correctly front-loaded, but the body is a sprawling enumeration that repeats the opening framing ('Answers questions about one Hawaiʻi lot, by TMK or street address') and then lists roughly thirty attributes, many of which are edge-case or island-specific (TVR standing on Kauaʻi, lava zone on Hawaiʻi Island). It is far longer than needed to select and invoke the tool, and the keyword-stuffed list hurts scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so thoroughly: every finding type, the fact that results are sourced and permalinked, and that one call covers the whole lot. Only the response shape (flat list vs. grouped sections) and error behavior remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters carry their own examples and formats, so the schema does the heavy lifting. The description confirms the two lookup modes exist but adds no format, precedence (what happens if both tmk and address are supplied, given neither is required), or normalization guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb+resource ('Look up one Hawaiʻi lot by TMK or street address') and enumerates the exact facts returned, so the agent knows precisely what the tool produces. The single-lot scope is clear, which implicitly distinguishes it from the sibling search_lots, though no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this when someone asks about one Hawaiʻi lot by TMK or street address' gives an explicit trigger condition and the two acceptable identifiers. It stops short of naming alternatives (e.g. search_lots for multi-lot or unknown-parcel lookups), so routing when the parcel identifier is not yet known 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.
Use this when someone wants nearby Hawaiʻi lots that fit zoning, size, flood zone or Special Management Area filters, around a lot, an address or a TMK prefix.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| sma | No | in or out of the Special Management Area | |
| flood | No | in: center in a FEMA special flood hazard area. out: not. | |
| limit | No | Up to 50. Default 25. | |
| island | No | Kauaʻi, Oʻahu, Maui County or Hawaiʻi Island. Not needed with tmk_prefix or near_tmk. | |
| zoning | No | Text to match in the zoning code or name, e.g. R-4, Agriculture, Resort | |
| near_tmk | No | Search around this lot | |
| radius_m | No | Meters around near_tmk or lat and lon. Default 500, up to 3000. | |
| max_acres | No | ||
| min_acres | No | ||
| tmk_prefix | No | Start of a TMK: island, zone, section and optionally plat, e.g. 4-4-2 or 4-4-2-016 | |
| near_address | No | Or around this Hawaiʻi street address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds no behavioral detail beyond that: nothing about result ordering, how radius defaults apply, whether anchors can be combined, or what happens when no anchor is supplied — which matters given all 13 parameters are optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the use case before the parameters. It is dense but not padded; a slight loss for being one long run-on with no separation between the filter and anchor concepts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter, zero-required spatial search with no output schema, the description should at minimum clarify the anchor set (it lists three of four, missing lat/lon) and whether anchors are one-of or combinable. It covers the common path but leaves the calling contract under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 69% schema coverage, the schema already documents most parameters. The description usefully groups them into filter dimensions versus location anchors, but omits lat/lon entirely, says nothing about how limit/radius_m interact with the anchors, and adds no syntax beyond the schema. This is roughly baseline value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (find nearby lots) on a specific resource (Hawaiʻi lots) with the filter dimensions (zoning, size, flood, SMA) and anchor modes (lot, address, TMK prefix). It is clearly a spatial search, distinct from siblings like get_parcel or get_listing_facts, though it never explicitly says how it differs from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when someone wants..." gives a concrete triggering scenario and enumerates the accepted search anchors. It lacks any when-not guidance or explicit routing to the sibling tools (get_parcel, get_clip), so it stops short of full alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_public_recordsget_listing_factsget_clipget_parcelget_public_recordssearch_lotsZoning, ADU eligibility, flood zone, setbacks, and buildability intelligence for U.S. parcels.
Property intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
Flood, wildfire, soils, terrain, power grid, utilities and parcels for any US location, sourced.
Any US address: flood, HUD rent, county tax. Parcel zoning/STR rules: Nashville, Denver, Scottsdale.
Add one secure layer between your agents and this server.
