Zoning, homes per lot, short-term rentals, tax and flood for any property in Austin and Nashville.
Scored across 3 tools
find_land (discovery of lots matching a need) and land_at (lookup on a specific address/coordinate) are related but distinguished by input type and intent, and search_businesses is clearly separate. There is minor room for confusion since both land tools answer zoning questions, but the search-vs-point-lookup boundary is generally clear.
All three names use snake_case, which is consistent. Two follow a verb_noun pattern (find_land, search_businesses) while land_at is noun_preposition, a minor deviation, and find/search are near-synonymous verbs, but the set remains readable and predictable.
Three tools is on the lean side for a surface spanning two cities and multiple domains (land search, property analysis, business search), and each tool is heavily overloaded with compound functionality. It is defensible and not bloated, but slightly under-decomposed.
The set covers the core lifecycle: discover candidate land, analyze a specific property, and find local businesses, with rich output links. Minor gaps exist, notably business coverage limited to Central Austin and no bulk/area-level export, but the main workflows are served.
Use when someone wants to find land or lots in Austin or Nashville that fit a need, for example lots where three homes are allowed, commercial land where apartments are allowed without a rezoning, dry industrial land of 5+ acres, zoning where whole-home short-term rentals are permitted, or Specific Plans whose ordinance bans rentals. Takes a ready-made view or a plain-English description of the need. Returns how many zoning areas and acres match, the largest ones, each with a point inside the zoning area, and a map link. Austin views: home3, sb840, co, interim, mfdry, ind5, hist, bsz. Nashville views: strok, spstr, ns, unbuilt, mfusd, ind5, hist, dadu.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | "austin" (City of Austin, Texas) or "nashville" (Nashville and Davidson County, Tennessee). Other cities are not covered. | |
| view | No | A ready-made view id for the city (see the description) | |
| limit | No | How many of the largest matches to return (default 10) | |
| request | No | Plain-English request instead of a view, for example 'apartments in the city core out of the floodplain' |
| Name | Required | Description |
|---|---|---|
| city | No | |
| next | No | |
| status | Yes | |
| largest | No | The largest matches, each with a point inside the zoning area |
| map_url | No | |
| message | No | |
| showing | No | The search in plain words |
| of_areas | No | |
| of_districts | No | |
| matching_acres | No | |
| matching_areas | No | Austin: zoning areas that match |
| matching_districts | No | Nashville: zoning districts that match |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful scope information beyond annotations: the two supported cities, the closed set of view ids, and what the response contains (match counts, acres, largest areas with an interior point, map link). No auth or rate-limit context, but that is minor here.
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?
Front-loaded with the trigger phrase and the resource, then layered with examples and the response summary. The view-id lists are lengthy but serve a real purpose since the schema has no enum. Only mild density cost from packing many examples into one long sentence.
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 4-parameter read tool with a pre-existing output schema and full annotation coverage, this is close to complete: cities, view vocabulary, request mode, and return shape are all addressed. The remaining gap is that the opaque view ids are listed without any gloss of what each represents, so an agent must guess which id maps to which need.
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% so the baseline is 3, but the description goes further by enumerating the view id vocabulary per city (home3, sb840, co, interim, mfdry, ind5, hist, bsz / strok, spstr, ns, unbuilt, mfusd, ind5, hist, dadu) and giving worked examples of natural-language requests. That compensates for the absence of schema enums on the view parameter.
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 verb-and-resource ('find land or lots'), scopes it to Austin and Nashville, and grounds it in concrete, recognizable use cases (3-home lots, dry industrial 5+ acres, STR zoning). This is clearly distinguishable from siblings land_at and search_businesses, which are point-lookup and business-oriented respectively.
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?
Opens with an explicit 'Use when...' trigger and enumerates several qualifying scenarios, which is strong when-to-use guidance. It also explains the two invocation modes (ready-made view vs. plain-English request). It does not, however, state when to prefer this over the sibling land_at, so sibling routing still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when someone asks what they can do with a specific property or address in Austin, TX or Nashville, TN: what it is zoned and what that means, how many homes the lot can take (Austin HOME rules, Texas SB 840 apartments on commercial land), what the zoning ordinance or Nashville Specific Plan says, whether a short-term rental (Airbnb) is allowed, the property tax and flood risk. Takes an address or a latitude and longitude. Returns the answer, the sources, a map link and a printable brief link. For a Nashville or Austin lot, when the paid Lot File is on sale in that city and covers the lot, it also returns lot_file: what the cited file adds (documents read, rules computed for the lot, pending cases) and the link to buy it.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | "austin" (City of Austin, Texas) or "nashville" (Nashville and Davidson County, Tennessee). Other cities are not covered. | |
| address | No | Street address, for example '1600 E 6th St' or '1600 Division St, 37203' | |
| latitude | No | ||
| homestead | No | Austin only: the owner's main home, so homestead exemptions apply (default true) | |
| longitude | No | ||
| property_class | No | Nashville only: taxed as a home (25%) or a business (40%); default follows the zoning | |
| appraised_value | No | Appraised value in dollars for the tax estimate (defaults: Austin 550000, Nashville 450000) |
| Name | Required | Description |
|---|---|---|
| lot | No | The lot's own records: size (Austin) or land use, building year, street frontage, service district and permit counts (Nashville) |
| city | No | |
| flood | No | |
| place | No | |
| point | No | |
| caveat | No | |
| status | Yes | ok: answered; choose: the address matches more than one place, choices lists them; not_found: no such address; no_zoning: the point is a street, water or outside the city; unsupported_city: not Austin or Nashville |
| zoning | No | The zoning code, what it means, overlays and the ordinance behind it |
| choices | No | |
| map_url | No | |
| message | No | |
| lot_file | No | Nashville and Austin, when the file is on sale in that city and covers the lot's zoning: the paid Lot File for this lot, what it adds to this answer, and where to buy it |
| brief_url | No | |
| point_note | No | |
| property_tax | No | |
| specific_plan | No | Nashville Specific Plan: what its ordinance says |
| zoning_ordinances | No | Austin zoning ordinances covering the point, newest first |
| short_term_rentals | No | Owner-occupied and whole-home short-term rental answers for this spot, each with its reason and source |
| what_you_can_build | No | Austin: how many homes the lot can take |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the geographic coverage limit ('other cities are not covered' in schema, two cities named here), the shape of the response (answer, sources, map link, printable brief), and the conditional Lot File upsell that only fires when the paid file is on sale and covers the lot. No rate limits, auth requirements, or failure modes are described.
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 trigger and the question list are front-loaded, which is the right ordering. It is a single dense paragraph, and the final Lot File sentence runs long, but that sentence earns its place by disclosing conditional return behavior rather than marketing filler.
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 an output schema present, return values need not be spelled out, yet the description still sketches them, and it covers coverage limits, input modes, and the optional paid artifact. For a read-only, idempotent lookup tool this is complete enough for an agent to call correctly; only auth/error behavior is absent.
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 71%, so the schema already carries most parameter meaning (city enum, homestead, property_class, appraised_value defaults). The description adds the useful point that either an address OR a latitude/longitude pair is acceptable, and ties the tax estimate output back to the appraised-value parameter. It does not explain how homestead or property_class change the answer, so it does not fully close the remaining coverage gap.
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 capability — answering 'what can I do with this property' questions — and enumerates the concrete resources covered (zoning, lot yield under Austin HOME / TX SB 840, ordinance or Nashville Specific Plan text, STR legality, property tax, flood risk). It is clearly a single-property lookup, which implicitly separates it from the sibling search tools find_land and search_businesses.
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?
It opens with an explicit trigger: 'Use when someone asks what they can do with a specific property or address in Austin, TX or Nashville, TN.' The city-scoping constraint is stated in both the description and the schema. However, it never names the sibling tools or says when to prefer find_land or search_businesses over this one, so routing between siblings 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 when someone wants a list of local businesses in Central Austin, TX by kind (for example dentists, coffee shops, plumbers), optionally only ones with no website listed or with a phone or email. Returns name, category, address, website status and contact details, each linked to its source record. Only Central Austin is covered.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results (default 20) | |
| query | No | What kind of business, for example 'dentist' or 'coffee' | |
| sector | No | ||
| contact | No | ||
| website | No | missing = no website listed (social pages only or none) |
| Name | Required | Description |
|---|---|---|
| more | No | Where to see every match, when there are more than returned |
| status | Yes | |
| results | Yes | Businesses: name, category, address, website status, contact details and source links |
| coverage | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context — the hard geographic coverage limit and that results are linked to source records — but says nothing about rate limits, result ordering, or behavior when the query matches nothing.
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?
Front-loaded trigger followed by filter semantics and a clear coverage caveat; every clause earns its place. Slightly long as a single breath, but there is no filler.
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?
An output schema exists, so return values need not be spelled out, and zero parameters are required, lowering the burden further. Coverage limits, filter intent, and result shape are all addressed; nothing essential for a correct call is missing.
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 60% schema coverage, the description compensates by explaining the query semantics ('by kind — dentists, coffee shops, plumbers') and the website/contact filters ('no website listed or with a phone or email'), including what 'missing' effectively means. Only limit and sector are left to 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?
States a specific verb (list/search) and resource (local businesses) narrowed by geography (Central Austin, TX) and by kind. The scope is unambiguous and trivially distinguishable from the land-oriented siblings find_land and land_at.
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?
Opens with an explicit trigger: 'Use when someone wants a list of local businesses... by kind', and later states the boundary 'Only Central Austin is covered', which functions as a when-not condition. It names no alternative tool, so it stops short of a 5.
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.
find_land1 field changedOutput schema / properties / largest / descriptionPrevious value: -"The largest matches, each with a point to pass to land_at"New value: +"The largest matches, each with a point inside the zoning area"land_at1 field changedOutput schema / properties / status / descriptionPrevious value: -"ok: answered; choose: the address matches more than one place, pick from choices; not_found: no such address; no_zoning: the point is a street, water or outside the city; unsupported_city: not Austin or Nashville"New value: +"ok: answered; choose: the address matches more than one place, choices lists them; not_found: no such address; no_zoning: the point is a street, water or outside the city; unsupported_city: not Austin or Nashville"land_at1 field changedOutput schema / properties / lot_file / descriptionPrevious value: -"Nashville, when on sale: the paid Lot File for this lot, what it adds to this answer, and where to buy it"New value: +"Nashville and Austin, when the file is on sale in that city and covers the lot's zoning: the paid Lot File for this lot, what it adds to this answer, and where to buy it"land_at1 field changedOutput schema / properties / lot_fileAdded value: +{
+ "additionalProperties": {},
+ "description": "Nashville, when on sale: the paid Lot File for this lot, what it adds to this answer, and where to buy it",
+ "properties": {
+ "adds": {
+ "type": "string"
+ },
+ "price": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "price",
+ "adds"
+ ],
+ "type": "object"
+}find_land4 fields changedInput schema / properties / city / descriptionAdded value: +"\"austin\" (City of Austin, Texas) or \"nashville\" (Nashville and Davidson County, Tennessee). Other cities are not covered."Input schema / properties / city / enumRemoved value: -[
- "austin",
- "nashville"
-]Input schema / properties / city / maxLengthAdded value: +60Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "city": {
+ "enum": [
+ "austin",
+ "nashville"
+ ],
+ "type": "string"
+ },
+ "largest": {
+ "description": "The largest matches, each with a point to pass to land_at",
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "map_url": {
+ "type": "string"
+ },
+ "matching_acres": {
+ "type": "number"
+ },
+ "matching_areas": {
+ "description": "Austin: zoning areas that match",
+ "type": "number"
+ },
+ "matching_districts": {
+ "description": "Nashville: zoning districts that match",
+ "type": "number"
+ },
+ "message": {
+ "type": "string"
+ },
+ "next": {
+ "type": "string"
+ },
+ "of_areas": {
+ "type": "number"
+ },
+ "of_districts": {
+ "type": "number"
+ },
+ "showing": {
+ "description": "The search in plain words",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "ok",
+ "bad_view",
+ "bad_request",
+ "unsupported_city"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}land_at4 fields changedInput schema / properties / city / descriptionPrevious value: -"austin (City of Austin, Texas) or nashville (Nashville and Davidson County, Tennessee)"New value: +"\"austin\" (City of Austin, Texas) or \"nashville\" (Nashville and Davidson County, Tennessee). Other cities are not covered."Input schema / properties / city / enumRemoved value: -[
- "austin",
- "nashville"
-]Input schema / properties / city / maxLengthAdded value: +60Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "brief_url": {
+ "type": "string"
+ },
+ "caveat": {
+ "type": "string"
+ },
+ "choices": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "latitude": {
+ "type": "number"
+ },
+ "longitude": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "label",
+ "latitude",
+ "longitude"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "city": {
+ "enum": [
+ "austin",
+ "nashville"
+ ],
+ "type": "string"
+ },
+ "flood": {
+ "type": "string"
+ },
+ "lot": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The lot's own records: size (Austin) or land use, building year, street frontage, service district and permit counts (Nashville)"
+ },
+ "map_url": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "place": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "point": {
+ "additionalProperties": false,
+ "properties": {
+ "latitude": {
+ "type": "number"
+ },
+ "longitude": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "latitude",
+ "longitude"
+ ],
+ "type": "object"
+ },
+ "point_note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "property_tax": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "short_term_rentals": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "owner_occupied": {
+ "type": "string"
+ },
+ "owner_occupied_detail": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "whole_home": {
+ "type": "string"
+ },
+ "whole_home_detail": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "owner_occupied",
+ "owner_occupied_detail",
+ "whole_home",
+ "whole_home_detail",
+ "note",
+ "source"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Owner-occupied and whole-home short-term rental answers for this spot, each with its reason and source"
+ },
+ "specific_plan": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Nashville Specific Plan: what its ordinance says"
+ },
+ "status": {
+ "description": "ok: answered; choose: the address matches more than one place, pick from choices; not_found: no such address; no_zoning: the point is a street, water or outside the city; unsupported_city: not Austin or Nashville",
+ "enum": [
+ "ok",
+ "choose",
+ "not_found",
+ "no_zoning",
+ "bad_request",
+ "unsupported_city"
+ ],
+ "type": "string"
+ },
+ "what_you_can_build": {
+ "additionalProperties": {},
+ "description": "Austin: how many homes the lot can take",
+ "properties": {
+ "details": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "headline": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "headline",
+ "details"
+ ],
+ "type": "object"
+ },
+ "zoning": {
+ "additionalProperties": {},
+ "description": "The zoning code, what it means, overlays and the ordinance behind it",
+ "properties": {},
+ "type": "object"
+ },
+ "zoning_ordinances": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ],
+ "description": "Austin zoning ordinances covering the point, newest first"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}search_businesses1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "coverage": {
+ "type": "string"
+ },
+ "more": {
+ "description": "Where to see every match, when there are more than returned",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "description": "Businesses: name, category, address, website status, contact details and source links",
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "enum": [
+ "ok"
+ ],
+ "type": "string"
+ },
+ "total_matches": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "status",
+ "coverage",
+ "total_matches",
+ "results"
+ ],
+ "type": "object"
+}find_landland_atsearch_businessesZoning, ADU eligibility, flood zone, setbacks, and buildability intelligence for U.S. parcels.
Zoning, parcel, and development feasibility for a street address in Canada and the US.
US parcels, owners, sales, zoning rules, building permits and zoning cases.
Title search, environmental reports, free US property data: loan limits, radon, flood, zoning, LLCs.
Add one secure layer between your agents and this server.
