GREENLANDAI

map_viewport

Read-only

Everything inside a bounding box (min_lat, min_lng, max_lat, max_lng): the true count per type for the whole box plus a capped sample of pins. Agent keys only. Metered: see CHARGING in the server instructions; quote first with billing_quote.

Input Schema

Name	Required	Description
`energy`	No	Include energy-fleet infrastructure and projects. Default false.
`fields`	No	Only these keys in each row (plus id). Omit for all.
`max_lat`	No	North edge of the bounding box (latitude).
`max_lng`	No	East edge of the bounding box (longitude).
`min_lat`	No	South edge of the bounding box (latitude). Send all four edges together.
`min_lng`	No	West edge of the bounding box (longitude).
`entity_type`	No	Entity kind: deposit \| infrastructure \| company \| project. Default all four.
`include_country_centroids`	No	Also return country-centre placeholder pins (entities known only by country). Default false.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedOct 29, 2026
- removedInput schema / properties / energy / title
```
Removed value: -"Energy"
```
- removedInput schema / properties / entity_type / default
```
Removed value: -null
```
- removedInput schema / properties / entity_type / title
```
Removed value: -"Entity Type"
```
- addedInput schema / properties / fields
```
Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Only these keys in each row (plus id). Omit for all."
+}
```
- removedInput schema / properties / include_country_centroids / title
```
Removed value: -"Include Country Centroids"
```
- removedInput schema / properties / max_lat / default
```
Removed value: -null
```
- removedInput schema / properties / max_lat / title
```
Removed value: -"Max Lat"
```
- removedInput schema / properties / max_lng / default
```
Removed value: -null
```
- removedInput schema / properties / max_lng / title
```
Removed value: -"Max Lng"
```
- removedInput schema / properties / min_lat / default
```
Removed value: -null
```
- removedInput schema / properties / min_lat / title
```
Removed value: -"Min Lat"
```
- removedInput schema / properties / min_lng / default
```
Removed value: -null
```
- removedInput schema / properties / min_lng / title
```
Removed value: -"Min Lng"
```
- removedInput schema / title
```
Removed value: -"map_viewportArguments"
```
- removedOutput schema / title
```
Removed value: -"map_viewportDictOutput"
```

Changed7 schema fields changedOct 17, 2026

addedInput schema / properties / energy / description

Added value: +"Include energy-fleet infrastructure and projects. Default false."

addedInput schema / properties / entity_type / description

Added value: +"Entity kind: deposit | infrastructure | company | project. Default all four."

addedInput schema / properties / include_country_centroids / description

Added value: +"Also return country-centre placeholder pins (entities known only by country). Default false."

addedInput schema / properties / max_lat / description

Added value: +"North edge of the bounding box (latitude)."

addedInput schema / properties / max_lng / description

Added value: +"East edge of the bounding box (longitude)."

addedInput schema / properties / min_lat / description

Added value: +"South edge of the bounding box (latitude). Send all four edges together."

addedInput schema / properties / min_lng / description

Added value: +"West edge of the bounding box (longitude)."

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "map_viewportDictOutput",
+  "type": "object"
+}

First observedSep 14, 2026

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: discloses that the call is metered, that a billing quote must precede it, that keys are agent-scoped, and that results are a capped sample while counts are exact for the full box. The exact cap size and whether it is paginable are left unstated, keeping this short of a 5.

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 bounding-box scope and the return shape, then the access and billing constraints. The telegraphic fragments ('Agent keys only.', 'Metered: see CHARGING...') are dense rather than padded, though the CHARGING reference is slightly cryptic without external context.

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 an 8-parameter, read-only tool with a full output schema and rich annotations, the description covers the gaps that matter: exact-vs-sampled results, metering, auth scope. Sampling behavior (cap size, pagination) and the all-four-edges requirement are handled by the schema, so nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all eight parameters including the four bbox edges and their validity. The description merely restates the four edge names and adds no format, ordering, or edge-case meaning beyond the schema's 'Send all four edges together' note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the resource and its scope precisely: a bounding-box query returning per-type counts plus a capped pin sample. That is enough to distinguish it from generic siblings, but it never names or contrasts it with the geo-adjacent siblings (nearby, look_at, look_from, look_through), so an agent must infer the split.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one hard prerequisite — quote with `billing_quote` first and consult CHARGING — which is genuinely actionable. It does not say when to choose map_viewport over the point/line-of-sight tools in the sibling list, so the when-vs-alternatives rule is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All GREENLANDAI tools Inspect

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

Need Help?