Geospatial System — Location Profile
Server Details
Elevation, slope, terrain maps & 3-D surfaces for any site — near-global 30 m, US 10 m, AU/NZ 5 m.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 9 of 9 tools scored.
Each tool targets a distinct resource and action: listing datasets, point elevation, batch elevation, elevation chart, elevation stats, slope chart, slope stats, 3D terrain, and terrain map. Their purposes are clearly separable even with similar names.
Seven tools follow a consistent LP_Get_ prefix pattern (e.g., LP_Get_Elevation, LP_Get_Elevation_Batch), but list_datasets breaks the pattern by using a different verb_noun style. This inconsistency reduces predictability.
Nine tools is an appropriate number for a geospatial location profile service. It provides focused functionality without being overwhelming, fitting well within the optimal range of 3-15 tools.
The set covers elevation and slope queries, statistics, charts, and terrain maps comprehensively. A minor gap is the lack of a single-point slope retrieval (only window statistics available) and detailed dataset metadata, but core workflows are well-supported.
Available Tools
9 toolslist_datasetsAInspect
List all available elevation datasets on the Geospatial System server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes the behavior as listing all available elevation datasets without any misleading or contradictory statements. No additional behavioral traits are necessary given the simplicity.
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 a single sentence with no wasted words, perfectly efficient for a simple list tool.
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 tool with zero parameters and a simple purpose, the description is complete. An output schema exists but is not needed; the description alone is sufficient for an agent to understand what the tool does.
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?
The tool has no parameters and the schema is empty. The description adds meaning beyond the schema by specifying that the tool lists 'all available elevation datasets' on the server, clarifying the scope and resource.
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 verb 'list' and the resource 'all available elevation datasets', and it distinguishes the tool from its siblings (which are about retrieving elevation/slope/terrain data for specific 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?
No explicit guidance on when to use this tool versus alternatives, but given its purpose is listing all datasets, it's straightforward and context implies it should be used before retrieving data from specific datasets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LP_Get_ElevationAInspect
Get the elevation in metres at a specific lat/lon coordinate. Available on all tiers including Free.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees (WGS-84). | |
| lon | Yes | Longitude in decimal degrees (WGS-84). | |
| dataset_id | Yes | Dataset identifier (see list_datasets). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it only states the operation is a fetch, lacking details on error handling, rate limits, or behavior for invalid coordinates.
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 core purpose, and includes an availability note without unnecessary detail.
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?
The description is adequate for a simple tool, but it could mention that dataset_id must come from list_datasets and provide usage context for sibling differentiation.
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 descriptions cover all 3 parameters; the tool description adds no new semantic information beyond what the schema already provides.
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 returns elevation in metres at a specific lat/lon coordinate, differentiating it from siblings like batch, chart, and slope tools.
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 'Available on all tiers including Free', indicating broad usage, but does not explicitly explain when to use this tool versus siblings like LP_Get_Elevation_Batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LP_Get_Elevation_BatchAInspect
Get elevation for up to 100 points in one call. Pass a list of objects: [{"lat":…,"lon":…,"dataset_id":…}, …] Available on all tiers including Free.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | List of point dicts with lat, lon, dataset_id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses limit of 100 points and tier availability. No annotations present, but description adequately covers key behavioral aspects for a read-only elevation lookup.
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 sentences with no extraneous information; action and format are front-loaded.
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 the output schema exists, the description provides sufficient context: batch size, input format, and availability. No additional details are needed.
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?
Adds explicit example of the expected object structure (lat, lon, dataset_id) beyond the schema's generic description, making parameter usage clear.
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 gets elevation for up to 100 points in one call, distinguishing it from single-point siblings like LP_Get_Elevation.
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 context on batch limit and tier availability, but does not explicitly state when to use batch vs single-point tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LP_Get_Elevation_ChartAInspect
Generate a range-box chart showing elevation Min/Avg/Max across three neighbourhood window sizes. Returns a URL to the chart image. Requires Pro key. Supports PNG / SVG / PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | Output format — 'png' (default), 'svg', or 'pdf'. | png |
| lat | Yes | Latitude in decimal degrees (WGS-84). | |
| lon | Yes | Longitude in decimal degrees (WGS-84). | |
| dataset_id | Yes | Dataset identifier. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return type (URL), supported formats (PNG/SVG/PDF), and the Pro key requirement. No destructive actions; safe read operation. Could mention additional details like rate limits, but acceptable.
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, front-loaded with the main purpose. No extraneous information; 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?
Given the presence of an output schema, description need not detail return format. It explains the chart content (elevation statistics across window sizes) and supported formats. Could elaborate on 'neighbourhood window sizes', but context signals show no nested objects, so complexity is moderate.
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. Description adds no new information about parameters beyond what the schema already states (e.g., fmt default, lat/lon in WGS-84, dataset_id as identifier). Adequate but not additive.
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?
Description clearly states it generates a range-box chart for elevation statistics (Min/Avg/Max) across three neighborhood window sizes, with a URL output. This distinguishes it from siblings like LP_Get_Elevation (raw values) and LP_Get_Elevation_Stats (statistics only).
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?
Mentions requirement for a Pro key, which is a usage prerequisite. Does not explicitly contrast with alternatives, but the purpose is clear enough for an agent to infer when to use this chart tool vs other elevation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LP_Get_Elevation_StatsAInspect
Get elevation statistics (Min, Average, Max) for 3×3, 5×5 and 7×7 pixel windows centred on the coordinates. Requires Pro or Enterprise key.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees (WGS-84). | |
| lon | Yes | Longitude in decimal degrees (WGS-84). | |
| dataset_id | Yes | Dataset identifier. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the access restriction (Pro/Enterprise key) and the pixel window sizes. It does not cover error handling or rate limits, but the behavioral traits that affect invocation (key requirement) are transparent.
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 with no unnecessary words. The first sentence defines functionality and window sizes; the second states the requirement. It is efficient and front-loaded.
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 the output schema exists, the description does not need to detail return values. It covers core functionality and the key prerequisite. It could be more complete by noting coordinate bounds or success/failure conditions, but for a 3-param tool, it is mostly adequate.
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. The description adds meaning by explaining that coordinates are used as centers for the windows and that dataset_id selects the elevation dataset. This enriches the parameter understanding 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 description clearly states it retrieves elevation statistics (Min, Average, Max) for specific pixel windows (3×3, 5×5, 7×7) centered on given coordinates. This differentiates it from sibling tools like LP_Get_Elevation (single point) and LP_Get_Elevation_Batch (batch processing).
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 the requirement for a Pro or Enterprise key, which is a usage prerequisite. However, it does not explicitly state when to choose this tool over siblings or provide exclusions. The context signals and sibling names help infer use cases, but direct guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LP_Get_Slope_ChartAInspect
Generate a range-box chart showing terrain slope Min/Avg/Max across three neighbourhood window sizes. Returns a URL to the chart image. Requires Pro key. Supports PNG / SVG / PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | Output format — 'png', 'svg', or 'pdf'. | png |
| lat | Yes | Latitude in decimal degrees (WGS-84). | |
| lon | Yes | Longitude in decimal degrees (WGS-84). | |
| dataset_id | Yes | Dataset identifier. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns a URL to a chart image, requires a Pro key, and supports multiple output formats. It does not mention any side effects, rate limits, or behavior for invalid inputs, but for a read-only chart generation tool this is fairly transparent.
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 three short sentences, front-loaded with the core action and output, and no redundant information. Every sentence contributes essential context.
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 the complexity (4 parameters) and the presence of an output schema, the description adequately covers the tool's functionality. It explains the output format and access requirement, though it could elaborate on the 'three neighbourhood window sizes' or chart details. Still, it is complete enough for an AI agent to select and invoke the tool correctly.
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 all parameters described in the schema. The description adds that the output is a URL and that the tool supports PNG/SVG/PDF, aligning with the 'fmt' parameter. However, it does not provide additional meaning beyond what the schema already documents, so baseline 3 is appropriate.
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 uses the specific verb 'Generate' and identifies the output as a 'range-box chart showing terrain slope Min/Avg/Max across three neighbourhood window sizes'. It clearly distinguishes from sibling tools like LP_Get_Elevation_Chart and LP_Get_Slope_Stats by focusing on slope chart generation.
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 'Requires Pro key' as a prerequisite but does not provide explicit guidance on when to use this tool versus alternatives. The purpose is inferable from the name and sibling list, but no when-to-use or when-not-to-use instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LP_Get_Slope_StatsAInspect
Get terrain slope statistics (Min, Average, Max) in degrees for 3×3, 5×5 and 7×7 pixel windows. WGS-84 corrected. Requires Pro key.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees (WGS-84). | |
| lon | Yes | Longitude in decimal degrees (WGS-84). | |
| dataset_id | Yes | Dataset identifier. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is WGS-84 corrected, requires a Pro key, and outputs stats for multiple window sizes. It does not contradict any implicit read-only behavior.
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 concise sentences, front-loaded with key information (verb, resource, output details, constraints). 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?
Given the existence of an output schema and 100% schema coverage, the description covers purpose, inputs, and behavioral context (WGS-84, Pro key). It is sufficiently complete for a stats retrieval 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 is 100%, so baseline is 3. The description adds little beyond the schema: it mentions WGS-84 correction, but that is already implied in the parameter descriptions. No additional parameter semantics are provided.
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 retrieves terrain slope statistics (Min, Average, Max) in degrees for three specific window sizes, with WGS-84 correction. This distinguishes it from sibling tools like LP_Get_Slope_Chart and LP_Get_Elevation_Stats.
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 implicitly suggests usage for obtaining slope stats and mentions the Pro key requirement, but lacks explicit when-to-use vs. alternatives guidance. However, the sibling list helps differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LP_Get_Terrain_3DAInspect
Generate a 3-D perspective terrain surface map (Plotly go.Surface) coloured by elevation with a red spike pin marking the query location. Requires Pro key. Supports PNG / HTML.
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | Output format — 'png', or 'html'. | png |
| lat | Yes | Latitude in decimal degrees (WGS-84). | |
| lon | Yes | Longitude in decimal degrees (WGS-84). | |
| offset | No | Half-window pixels (default 20). | |
| azim_angle | No | Camera azimuth angle in degrees (default 135). | |
| dataset_id | Yes | Dataset identifier. | |
| elev_angle | No | Camera elevation angle in degrees (default 45). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency burden. It discloses the use of Plotly go.Surface, elevation coloring, a red spike pin, output formats (PNG/HTML), and the Pro key requirement. This adequately informs the agent of the tool's nature and output, though potential pitfalls (e.g., coordinate limits) are omitted.
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 long, front-loading the core purpose and key details (elevation coloring, spike pin, output formats, Pro requirement). Every sentence is essential, 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?
Given the tool's complexity (7 parameters) and presence of an output schema, the description covers the essential behavioral aspects: output type, visual elements, and access requirement. It could optionally mention data source or coordinate ranges, but it is sufficient for an agent to understand the tool's value.
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 parameter descriptions already informative (e.g., lat/lon in decimal degrees, default angles). The description does not add additional meaning beyond stating the output is a Plotly surface; it merely repeats high-level intent.
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?
Description clearly states 'Generate a 3-D perspective terrain surface map (Plotly go.Surface) coloured by elevation with a red spike pin marking the query location.' This specifies the unique output type, verb, and distinguishing features against sibling tools like LP_Get_Terrain_Map (likely 2D).
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 'Requires Pro key' but does not provide explicit guidance on when to use this tool versus its siblings (e.g., LP_Get_Terrain_Map, elevation tools). While the context is implied, no alternatives or exclusion criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LP_Get_Terrain_MapAInspect
Generate a composite terrain map: Google Hybrid satellite (EPSG:3857) + smoothed contours with labels + flow-direction arrows + location pin. All layers are reprojected to EPSG:3857 — no overlay mismatch. Requires Pro key. Supports PNG.
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | Output format — 'png'. | png |
| lat | Yes | Latitude in decimal degrees (WGS-84). | |
| lon | Yes | Longitude in decimal degrees (WGS-84). | |
| offset | No | Half-window pixels (default 20 → 41×41 px area). | |
| n_arrows | No | Flow arrow grid density (default 11). | |
| dataset_id | Yes | Dataset identifier. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It describes the output composition, reprojection to avoid mismatch, and format support. It could add more on rate limits or error behavior, but the inclusion of output schema compensates partially.
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?
Four sentences, each adding unique value: components, reprojection, requirement, format. No redundancy, front-loaded with purpose.
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 output schema exists and moderate parameter count, the description is thorough. It explains what the tool does and key constraints. Minor omission: could explicitly mention the output is an image, but output schema likely covers it.
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 overall context (reprojection, overlays) but does not enhance individual parameter meanings 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 description explicitly states the tool generates a composite terrain map listing specific components (satellite, contours, arrows, pin) and reprojection. It clearly distinguishes from sibling tools that handle elevation or stats.
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 a prerequisite (Pro key) but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings. Usage is implied by the tool's composite nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!