Township America MCP Server: PLSS Lookup for AI Agents

AI land tools have a gap you hit the moment they get useful. An agent can read a lease, parse T49N R73W Sec 22, 6th Principal Meridian out of the legal description, and reason about what it means — but ask it where that parcel actually sits, and it guesses. The coordinates aren't in its training data. The PLSS MCP server closes that gap: it gives any AI agent a direct line to convert a legal description to latitude/longitude, mid-conversation, against real survey data.

This post covers what the server does, how to install it in a few minutes, and where it earns its place in AI-assisted title and APD work.

The missing data layer in AI land tools

A model can explain that T49N R73W Sec 22 is one square mile in Campbell County, Wyoming. It cannot tell you the corner coordinates, because the BLM survey record that fixes them was never something it memorized. So every AI land assistant ends up bolted to a converter through custom glue code — an API wrapper, a function-calling shim, a context switch to another tab.

The Model Context Protocol removes that glue. MCP is an open standard for handing tools to an AI agent in a way it can call on its own. The Township America PLSS MCP server speaks that protocol, so the agent gains coordinate lookup the same way it gains any other tool — declared once, then available for the rest of the session.

What the PLSS MCP server does

The server exposes three tools over stdio transport. Each one is a thin door onto the same survey data behind the Township America API:

• plss_to_latlon — takes a legal description and returns latitude/longitude plus the parcel boundary.
• latlon_to_plss — takes a coordinate pair and returns the Section-Township-Range that contains it.
• batch_plss_convert — takes up to 100 descriptions in one call, for well tables and title runs.

All three read BLM GCDB source records and cover all 30 PLSS states and 37 principal meridians. The agent picks the tool; you don't write the request.


Install and configure in a few minutes

The server ships with the Python package. Install it with the mcp extra:

pip install townshipamerica[mcp]

If you'd rather not install anything, run it on demand with uvx:

uvx --from townshipamerica[mcp] townshipamerica-mcp

Then register it with your AI agent. In Claude Desktop or Claude Code, add the server to a .mcp.json file:

{
  "mcpServers": {
    "townshipamerica": {
      "command": "uvx",
      "args": ["--from", "townshipamerica[mcp]", "townshipamerica-mcp"],
      "env": {
        "TOWNSHIP_AMERICA_API_KEY": "ta_live_your_key_here"
      }
    }
  }
}

The server reads your TOWNSHIP_AMERICA_API_KEY from the environment — the same key that runs the REST API and the Python SDK. Restart the agent, and the three PLSS tools show up in its tool list. That's the whole setup.

A real lookup, mid-conversation

Here is the part that changes the workflow. You ask your assistant a question in plain language, and it runs the conversion itself instead of handing you a description to look up later.

You: "Where is T49N R73W Sec 22 in Wyoming, and which county?"

The agent calls the tool:

plss_to_latlon({
  "description": "T49N R73W Sec 22",
  "meridian": "6th Principal Meridian"
})

And gets back a structured result it can fold into its answer:

{
  "latitude": 44.2871,
  "longitude": -105.6433,
  "county": "Campbell",
  "state": "WY",
  "meridian": "6th Principal Meridian",
  "geometry": { "type": "Polygon", "coordinates": [ ... ] }
}

No copy-paste, no second tab. The reverse works the same way: hand the agent a coordinate pair from a field GPS unit and latlon_to_plss returns the Section-Township-Range that the permit needs. For an explanation of why the meridian has to be named — and how reading a description like this works — the PLSS reference covers it.


Where it fits: AI title and APD workflows

The agent tools matter most where someone is already building an assistant for land professionals.

AI-assisted APD filing. A drafting agent reads the well plan, extracts each Section-Township-Range, and calls batch_plss_convert to verify coordinates before the BLM Form 3160-3 goes out — the same coordinate step land departments automate with the API, now driven by the agent.

Title examination co-pilot. An examiner pastes a chain of aliquot parts; the assistant resolves each one to a parcel and flags the descriptions that don't close.

Lease management agent. A pipeline ingesting new leases reverse-geocodes coordinates back to legal descriptions for the database of record, with no human in the loop.

In each case the agent decides when a lookup is needed. The server just answers.

The landman AI landscape, and why the timing matters

AI title automation is the loudest conversation in the land business right now. Landman.ai, TitleTrackr, and Tracts are all racing to read runsheets and draft title opinions with language models. They are good at the reasoning. They share the same blind spot: none of them resolve a legal description to a real coordinate on their own.

That is the layer the PLSS MCP server supplies. Drop it into any of those workflows — or a custom AI agent of your own — and the reasoning gets a verified location underneath it. No competitor has shipped an AI-agent PLSS integration on an open standard, which makes this the moment to build on it rather than wait.

Get a key and start building

The PLSS MCP server is one install and one environment variable away from running inside your AI agent today. Grab an API key from the API page — the same key powers the REST endpoints, the Python SDK, and the MCP server. If you'd rather check the math by hand first, the PLSS converter resolves any description in the browser, and pricing lays out the plans for moving from a test key to production volume.

Three tools, one install, all 30 PLSS states — and your agent stops guessing where the parcel is.