Skip to main content
Glama

MapLedger

by app.mapledger
OverviewDiscussionsAdmin

Find land that fits

find_land
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
cityYes"austin" (City of Austin, Texas) or "nashville" (Nashville and Davidson County, Tennessee). Other cities are not covered.
viewNoA ready-made view id for the city (see the description)
limitNoHow many of the largest matches to return (default 10)
requestNoPlain-English request instead of a view, for example 'apartments in the city core out of the floodplain'

Output Schema

NameRequiredDescriptionDefault
cityNo
nextNo
statusYes
largestNoThe largest matches, each with a point inside the zoning area
map_urlNo
messageNo
showingNoThe search in plain words
of_areasNo
of_districtsNo
matching_acresNo
matching_areasNoAustin: zoning areas that match
matching_districtsNoNashville: zoning districts that match

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / largest / description
      Previous 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"
  2. Changed4 schema fields changed
    • addedInput schema / properties / city / description
      Added value: +"\"austin\" (City of Austin, Texas) or \"nashville\" (Nashville and Davidson County, Tennessee). Other cities are not covered."
    • removedInput schema / properties / city / enum
      Removed value: -[
-  "austin",
-  "nashville"
-]
    • addedInput schema / properties / city / maxLength
      Added value: +60
    • changedOutput 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"
+}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

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, 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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All MapLedger toolsInspect
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.

Resources