Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@terranode-co/mcp-server What county is latitude 40.71, longitude -74.00 in?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for spatial queries via the Terranode Geospatial API. Gives AI agents (Claude Desktop, Cursor, etc.) tools to query geospatial datasets — point-in-polygon lookups, nearest feature search, distance calculations, and spatial joins.
Node.js 18+
A Terranode API key — sign up at app.terranode.co
Related MCP server: Overture Maps MCP Server
Add to your claude_desktop_config.json:
{
"mcpServers": {
"terranode": {
"command": "npx",
"args": ["@terranode-co/mcp-server"],
"env": {
"TERRANODE_API_KEY": "your-api-key-here"
}
}
}
}Add to your Cursor MCP settings (.cursor/mcp.json):
{
"mcpServers": {
"terranode": {
"command": "npx",
"args": ["@terranode-co/mcp-server"],
"env": {
"TERRANODE_API_KEY": "your-api-key-here"
}
}
}
}Add to your Claude Code MCP settings:
{
"mcpServers": {
"terranode": {
"command": "npx",
"args": ["@terranode-co/mcp-server"],
"env": {
"TERRANODE_API_KEY": "your-api-key-here"
}
}
}
}Tool | Description |
| List all available geospatial datasets (system + custom) |
| Point-in-polygon: which feature contains a coordinate? |
| Find the N nearest features to a coordinate, with distances |
| Geodesic distance between two points (meters + miles) |
| Enrich multiple coordinates with polygon attributes at once |
Try these in Claude Desktop or Cursor:
"What county is latitude 40.71, longitude -74.00 in?"
"What datasets are available?"
"Find the 3 nearest counties to Central Park"
"How close is my proposed site (40.7128, -74.006) to the nearest school (34.0522, -118.2437)?"
"Which states do these 5 warehouse locations fall in?" (paste coordinates)
"What ZIP code is 37.7749, -122.4194 in?"
The full API spec is available at docs.terranode.co/openapi.yaml (OpenAPI 3.1).
Report issues or feature requests: feedback@terranode.co
Calculate the exact geodesic distance between two points on Earth's surface. Uses the WGS84 ellipsoid model for high accuracy. No dataset needed. Returns distance in both meters and miles.
| Name | Required | Description | Default |
|---|---|---|---|
| lat1 | Yes | Latitude of first point | |
| lng1 | Yes | Longitude of first point | |
| lat2 | Yes | Latitude of second point | |
| lng2 | Yes | Longitude of second point |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the WGS84 ellipsoid model and return format (meters and miles). However, it omits error handling, input validation, or precision limits. Adequate but not exhaustive.
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 description is two sentences, front-loaded with the main purpose, and provides essential details without any wasted words.
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?
Given no output schema, the description explains return values (meters and miles). Parameters are fully described in schema. Sibling tools are clearly distinct, and context is complete for this simple calculation tool.
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%, so baseline is 3. The tool description does not add significant meaning beyond the schema's parameter descriptions (e.g., does not specify valid coordinate ranges or decimal degree format).
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 clearly states it calculates geodesic distance between two points on Earth's surface. It specifies high accuracy using WGS84 ellipsoid, and the purpose is distinct from sibling tools (check_location, enrich_location, find_nearest, list_datasets, spatial_join).
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?
The description mentions 'No dataset needed', implying standalone use, but lacks explicit guidance on when to use this tool versus alternatives (e.g., spatial_join). There are no exclusions or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check which feature in a polygon dataset contains a given coordinate (point-in-polygon query). Returns the properties of all matching features, or indicates no match. Requires latitude, longitude, and a dataset id (UUID) from list_datasets. Call list_datasets first to get the id. This is NOT a geocoder — it requires numeric coordinates, not addresses or place names.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees (WGS84). Example: 40.7128 | |
| lng | Yes | Longitude in decimal degrees (WGS84). Example: -74.0060 | |
| dataset | Yes | Dataset id (UUID) from list_datasets |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return behavior ('Returns properties of all matching features, or indicates no match') but does not disclose potential side effects or permission requirements. Since no annotations are provided, the description carries the full burden, and it falls short of fully disclosing operational traits.
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?
Three efficient sentences: first defines purpose, second describes output, third states requirements and disclaimers. Front-loaded with the core action, no wasted words.
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?
Given no output schema, it adequately describes the return value. For a simple point-in-polygon query with three parameters, it covers inputs, prerequisites, and what to expect. Minor gap: no mention of error handling or output data format.
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 baseline is 3. The description adds minimal extra meaning beyond the schema, only noting that the dataset id comes from list_datasets. No additional constraints or examples beyond what is in 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?
Clear verb+resource ('check which feature in a polygon dataset contains a given coordinate') and explicitly distinguishes from siblings by stating it is NOT a geocoder and requires numeric coordinates, making its purpose unambiguous.
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?
Explicitly states prerequisites (call list_datasets first to get the dataset id) and provides a clear when-not-to-use condition (not for addresses or place names), guiding appropriate usage against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get location attributes (county, flood zone, school district, etc.) for a coordinate. Queries all available datasets in one call and returns what matched. No dataset id needed — this is the simplest way to find out what's at a location. Optional radius expands the search area (meters). This is NOT a geocoder — it requires numeric coordinates, not addresses or place names.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees (WGS84). Example: 40.7128 | |
| lng | Yes | Longitude in decimal degrees (WGS84). Example: -74.0060 | |
| radius | No | Expand search area by this radius in meters (max 500000). Omit for exact matches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behaviors: queries all datasets in one call, returns what matched, optional radius. Missing details on error handling or limits, but sufficient for typical use.
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?
Three sentences, each essential: purpose, usage note, and critical exclusion (geocoder). Front-loaded, no redundancy.
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?
Covers all essential aspects for a simple lookup tool with no output schema. Explains input, behavior, and what it returns. Could mention limits like max radius, but schema already provides that.
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 baseline is 3. Description adds minor context ('simplest way') but does not significantly enhance understanding beyond schema. No new constraints or formats.
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?
Clear verb ('Get location attributes'), specific resource ('location attributes'), and distinguishes from siblings by stating it's not a geocoder and doesn't need dataset id. Defines scope exactly.
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?
Explicitly states when to use ('simplest way') and when not ('NOT a geocoder'). Provides context on optional radius. Does not explicitly name alternative sibling tools but implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the nearest counties, districts, ZIP codes, or other features to a coordinate. Use this for proximity queries, finding what's nearby, or ranking features by distance. Returns features sorted by distance (meters and miles), measured to feature boundary. Also works as a reverse lookup — returns the containing feature (distance=0) plus neighbors. Requires latitude, longitude, and a dataset id (UUID) from list_datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees (WGS84) | |
| lng | Yes | Longitude in decimal degrees (WGS84) | |
| dataset | Yes | Dataset id (UUID) from list_datasets | |
| n | No | Number of nearest features to return (max 20, default 1) | |
| radius | No | Maximum search radius in meters (max 500000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses behavior: returns features sorted by distance (meters and miles), measured to feature boundary, and includes reverse lookup (containing feature with distance=0). No side effects or auth needs mentioned, but adequate for a read-only 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?
Three sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
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?
No output schema, but description explains return format (features sorted by distance, in meters and miles). Also mentions reverse lookup behavior. Almost complete; could mention return structure but sufficient for a simple tool.
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 100%, and the description adds context: explains that dataset UUID comes from list_datasets, and mentions max values for n (20) and radius (500000) which are already in schema. Provides meaning beyond 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?
Clearly states the tool finds nearest features (counties, districts, ZIP codes) to a coordinate, with a specific verb 'find' and resource 'nearest features'. Distinguishes from siblings by mentioning proximity queries and reverse lookup.
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?
Explicitly says use for proximity queries, finding what's nearby, ranking by distance, and reverse lookup. Does not explicitly state when not to use or compare to sibling tools like calculate_distance, but the description provides good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all geospatial datasets available for querying. Returns pre-loaded public datasets (US states, counties, ZIP codes, etc.) and your custom uploaded datasets. Each dataset has an id (UUID) — always use the id when calling other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return content (public and custom datasets) and important ID usage, but lacks details on pagination, ordering, or read-only nature, especially since no annotations exist.
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?
Three concise sentences efficiently convey purpose, content, and a critical usage instruction with no wasted words.
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?
Adequate for a simple listing tool, but missing details about response structure (e.g., additional dataset properties) given no output schema.
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 zero parameters and 100% schema coverage, the description adds value by explaining what datasets are returned and emphasizing ID usage, meeting the baseline of 4.
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 clearly states the tool lists all geospatial datasets, distinguishing it from sibling tools that perform operations on locations.
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 implicitly recommends using this tool first by stating to always use the dataset id in other tools, but does not explicitly say when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich a set of coordinates with attributes from a polygon dataset. For each point, returns the properties of the polygon it falls within. Like running check_location on multiple points at once, but more efficient. Requires an array of coordinate objects and a dataset id (UUID) from list_datasets. Call list_datasets first to get the id. Points need numeric coordinates, not addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| points | Yes | Array of {lat, lng} objects. Optional "properties" on each point are passed through in results. Max 100 points (free tier) or 1000 points (paid tier). | |
| dataset | Yes | Dataset id (UUID) from list_datasets |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes core behavior (returns properties of containing polygon) and efficiency, but omits details on output format, handling of points outside polygons, or error conditions. With no annotations, the description carries full burden but doesn't cover edge cases.
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?
Three concise sentences: purpose comparison to sibling prerequisite. No wasted words, front-loaded with key 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?
Covers main usage and prerequisite, but lacks output details and error cases. Given no output schema, description could be slightly more complete, but is adequate for typical use.
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 parameters are well-documented. Description adds value by reiterating prerequisite (dataset id from list_datasets) and coordinate requirement, but does not significantly expand 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?
Clearly states it enriches coordinates with polygon attributes and compares to sibling check_location, making the purpose and distinction obvious.
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?
Provides clear prerequisite (call list_datasets first) and notes coordinate requirements. Implicitly suggests when to use this over check_location (multiple points), but lacks explicit when-not-to-use guidance.
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. Dates show when Glama detected each change.
v0.1.10calculate_distancecheck_locationenrich_locationfind_nearestlist_datasetsspatial_joinTools have distinct purposes but check_location and enrich_location both perform point-in-polygon queries, which could cause confusion. However, clear descriptions differentiate their scopes (single vs. multi-dataset).
All tools follow a consistent verb_noun pattern with lowercase and underscores, e.g., calculate_distance, list_datasets, spatial_join.
Six tools cover essential geospatial operations without excess or deficiency, well-scoped for a geospatial analysis server.
Covers core geospatial queries (distance, point-in-polygon, enrichment, proximity) but lacks tools for dataset upload, detailed metadata, or buffer/area calculations. Minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
MCP server for Mireye Earth — federal-source-cited geospatial data for any MCP-aware agent.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/terranode-co/mcp-server-terranode'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
