The Gods Eye Geospatial MCP server provides sovereign, open-licence geospatial awareness for AI agents, wrapping APIs such as ESA Copernicus Sentinel, OpenStreetMap, Overture, Ordnance Survey UK, INSPIRE EU, and DEFRA behind an ethics gate. It supports use cases including AI-agent situational awareness, environmental compliance, and disaster response (explicitly excluding kinetic/military operations).
Capabilities:
List Data Sources: Retrieve all available open-licence geospatial data sources (e.g. Copernicus Sentinel-1/2/3/5p, OpenStreetMap, OS UK, INSPIRE EU, DEFRA).
Situational Query: Plan a geospatial situational-awareness query using natural language, optionally scoped by bounding box, named area of interest (AOI), and time window. Returns a structured plan of data sources, products, processing steps, and Care Membrane ethics gate status. (Actual tile fetching is a Pro-tier feature.)
Check Data Provenance: Analyse a geospatial stack description to flag proprietary or closed-licence dependencies and suggest open-licence, EU/UK-hosted alternatives — useful for GDPR compliance, data-residency requirements, CSRD reporting, and open-data mandates.
Care Membrane Policy: Retrieve the ethical policy governing what the server will and will not do.
Sign Data Provenance Attestation (Pro/Enterprise): Generate a cryptographically signed (HMAC-SHA256) attestation of data provenance, including an open-licence score, public verify URL, and optional board-ready PDF — suitable for CSRD E3/E4 evidence packs, GDPR Article 30 records, and municipal open-data procurement.
Provides tools for geospatial queries and spatial analysis using OpenStreetMap data, enabling AI agents to access geographic information for environmental compliance, disaster response, and situational awareness.
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., "@Gods Eye Geospatial MCP get latest satellite image for London"
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.
Gods Eye — sovereign geospatial awareness MCP
Gods Eye — sovereign geospatial awareness MCP. Wraps open, non-US-dependent APIs (ESA Copernicus Sentinel-1/2/3/5p, OpenStreetMap, Overture, Ordnance Survey UK, INSPIRE EU, DEFRA) behind the MEOK Care Membrane ethics gate. For AI-agent situational awareness, environmental compliance, disaster response. Not for kinetic operations. By MEOK AI Labs.
# Install via pip
pip install gods_eye_geospatial_mcp
# Or install via Smithery
npx -y @smithery/cli@latest install gods-eye-geospatial-mcp --client claudeRelated MCP server: mapsi-mcp
MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance
This MCP server is built with EU AI Act compliance built-in:
✅ Article 9 — Risk Management System
✅ Article 13 — Transparency & Instructions for Use
✅ Article 15 — Bias Detection & Testing
✅ Article 26 — FRIA Support (where applicable)
✅ Article 50 — AI Content Watermarking (where applicable)
Need help getting compliant? Book a free 15-min diagnostic →
Need custom development, SLA guarantees, or white-label deployment?
Pro: $99/mo — Full MCP suite + EU AI Act tracking
Enterprise: $499/mo — Custom dev + SLA + Dedicated support
View Pricing → | Contact Sales →
This server is part of the MEOK AI Labs ecosystem — 300+ MCP servers for sovereign AI governance.
Domain | Purpose |
EU AI Act compliance marketplace | |
AI safety & monitoring | |
Sovereign AI platform | |
Legacy modernization |
MIT © CSOAI-ORG
Tier | Price | What you get | Stripe |
Smoke test | £1 | Signed sample MCP-Hardening report + Article 50 PDF | |
Quick Kit | £9 | EU AI Act Article 50 implementation guide (C2PA + EU-Icon) | |
Founder Call | £29 | 30-min 1-on-1 with the founder |
Refundable. UK Stripe — VAT-clean. Builds on the 81-MCP MEOK fleet. Verify any signed report at https://meok.ai/verify.
Add to your claude_desktop_config.json (Claude Desktop) or your MCP client config:
{
"mcpServers": {
"gods-eye-geospatial-mcp": {
"command": "uvx",
"args": ["gods-eye-geospatial-mcp"]
}
}
}Or: pip install gods-eye-geospatial-mcp then run the gods-eye-geospatial-mcp command (stdio transport).
Once configured, ask your assistant, for example:
"Use list_data_sources to …"
"Use situational_query to …"
"Use check_data_provenance to …"
Return the Care Membrane policy governing what Gods Eye will and will not do.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavioral traits. It does not state that the call is read-only, safe, or has no side effects. It only says 'Return', implying idempotence, but fails to explicitly confirm safety or mention authentication needs.
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, but it lacks structure or supplementary information. It meets the minimum standard but provides no additional 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?
Despite low complexity and the presence of an output schema, the description fails to cover the parameter or explain the tool's role within the tool ecosystem. It is too sparse to be considered complete for effective agent usage.
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 0%; the description completely ignores the single optional parameter 'api_key'. The description adds no meaning beyond the schema, despite the need to compensate for low coverage.
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 action ('Return'), the resource ('Care Membrane policy'), and the scope ('what Gods Eye will and will not do'). It is distinct from sibling tools which focus on data provenance and queries.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a geospatial stack description, flag proprietary / closed-licence dependencies and suggest open-licence, EU/UK-hosted alternatives. Useful for civilian projects with GDPR, data-residency, or open-data mandates (environmental NGOs, municipalities, research groups, CSRD reporters, agriculture co-ops).
| Name | Required | Description | Default |
|---|---|---|---|
| stack_description | Yes | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implies a read-only analysis tool. It describes the action and target but lacks details on side effects, required permissions, or whether the api_key parameter affects behavior. This is adequate but not thorough.
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: the first clearly states the action, the second lists use cases. No unnecessary words, well-structured 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?
The description explains input and use cases, and an output schema exists so return details are covered. It lacks mention of potential error conditions or internet access requirements, but is sufficient for most scenarios.
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 schema has 0% description coverage. The tool description adds meaning for the 'stack_description' parameter ('geospatial stack description') but does not mention the optional 'api_key' parameter. Partial compensation for a low-coverage 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 the tool flags proprietary dependencies and suggests open-licence alternatives for a geospatial stack. This distinguishes it from siblings like list_data_sources or sign_data_provenance_attestation, which have different purposes.
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 specifies when to use the tool: civilian projects with GDPR, data-residency, or open-data mandates. It provides clear context but does not explicitly exclude scenarios or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the open-licence geospatial data sources wrapped by Gods Eye.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It implies a read-only operation ('List') but does not explicitly state that the tool is non-destructive, requires no authentication beyond an optional API key, or has rate limits. No side effects or constraints are disclosed.
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, clear sentence with no fluff. It is appropriately sized for a simple list tool and front-loads the action verb 'List'.
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 simplicity (1 optional param) and the presence of an output schema (not shown), the description is minimally adequate. However, it could add context about what the returned list contains (e.g., IDs, names, metadata) to improve completeness.
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 input schema has one undocumented parameter 'api_key' (0% schema description coverage). The description does not mention this parameter at all, failing to explain its purpose, format, or when it is needed.
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 'open-licence geospatial data sources wrapped by Gods Eye,' providing a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'check_data_provenance' or 'situational_query,' though the name implies a listing function.
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 offers no guidance on when to use this tool versus alternatives. No exclusions, prerequisites, or context are provided, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a cryptographically signed data-provenance attestation for your geospatial stack (Pro/Enterprise).
Produces HMAC-SHA256 signed JSON + public verify URL + optional board-ready PDF. Useful for CSRD E3/E4 evidence packs, GDPR Article 30 processing records, and municipal open-data mandates. Your auditor or procurement team validates the verify_url without needing to reach our backend.
open_licence_score: 0-100 from check_data_provenance
findings_csv: comma-separated findings (e.g. "Copernicus PASS — free + open,Google Maps GAP — proprietary")
include_pdf_base64: True to receive PDF as base64
| Name | Required | Description | Default |
|---|---|---|---|
| entity_name | Yes | ||
| stack_description | Yes | ||
| open_licence_score | Yes | ||
| findings_csv | No | ||
| include_pdf_base64 | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially explains behavior: it produces HMAC-SHA256 signed JSON, a public verify URL, and optional PDF. It mentions offline validation but does not disclose auth requirements (api_key), mutation semantics, or error handling. Key parameters like entity_name and stack_description are not described.
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 concise, with a clear overview sentence and bullet points for key parameters. It is front-loaded with purpose, but the bullets could be more consistently structured. No wasted sentences.
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 6 parameters, no annotations, and an output schema, the description is incomplete. It does not explain the output structure, the required input parameters (entity_name, stack_description, api_key), or the prerequisite step (check_data_provenance). Adequate for basic understanding but lacks detail.
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 description adds meaning for 3 out of 6 parameters (open_licence_score, findings_csv, include_pdf_base64) by explaining their source and format. However, it omits semantics for entity_name, stack_description, and api_key, and schema coverage is 50% (3 of 6 parameters mentioned).
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 generates a cryptographically signed data-provenance attestation, specifying the verb 'Generate', the resource 'attestation', and the context 'geospatial stack'. It distinguishes from siblings like check_data_provenance and list_data_sources by focusing on signing, not checking or listing.
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 explicitly mentions use cases such as CSRD E3/E4 evidence packs, GDPR Article 30 records, and municipal mandates, indicating when to use. It also hints at external validation by auditors, but does not directly contrast with siblings or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan a geospatial situational-awareness query. Pass natural-language 'query' plus bounding box (minLon,minLat,maxLon,maxLat) or 'aoi_name' (an administrative area name).
Returns a structured plan: which data sources to use, which products to fetch, how to chain them, and Care Membrane status. Actual tile fetching is a Pro-tier feature.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| bbox | No | ||
| aoi_name | No | ||
| time_window | No | last_7_days | |
| preferred_sources | No | copernicus_sentinel_2,openstreetmap | |
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states the tool returns a structured plan and does not perform actual data fetching (Pro-tier). However, it does not mention whether the tool is read-only, has side effects, or requires specific authentication (api_key parameter is listed but not explained). The disclosure is not complete, but it provides some useful behavioral context.
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 concise (three sentences) and effectively front-loaded: first sentence states purpose, second lists input variations, third describes output and a limitation. There is no redundancy or wasted wording.
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 has an output schema (so return values are defined elsewhere) but schema coverage is 0% and no annotations exist, the description partially compensates by explaining the output conceptually. However, it fails to specify that bbox and aoi_name are mutually exclusive, does not detail the exact format of the bound box, and does not explain the meaning of all parameters. The description is adequate but leaves notable gaps for an agent to fully use the 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?
The input schema has 0% description coverage, so the description must add meaning. It explains that 'query' is natural language and describes the optionally alternatives of 'bbox' (with format minLon,minLat,maxLon,maxLat) and 'aoi_name'. However, it does not clarify 'time_window', 'preferred_sources', or 'api_key', leaving gaps in understanding those parameters.
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's purpose: to plan a geospatial situational-awareness query. It specifies the inputs (natural-language query plus bbox or aoi_name) and outputs (structured plan). This distinguishes it from sibling tools like care_membrane_policy or list_data_sources, which have different functions.
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 explains how to use the tool (provide query and either bbox or aoi_name) and notes that tile fetching is a Pro-tier feature. However, it does not explicitly state when to use this tool versus alternatives or provide any context about prerequisites or exclusions, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a clearly distinct purpose: policy retrieval, provenance checking, data source listing, attestation signing, and query planning. No overlap in functionality.
Naming patterns are inconsistent: 'care_membrane_policy' is a noun phrase, while 'check_data_provenance' and 'list_data_sources' follow verb_noun, but 'sign_data_provenance_attestation' is verbose, and 'situational_query' is adjective_noun. No consistent convention.
With 5 tools, the server is well-scoped for its focus on geospatial data provenance and situational awareness. Each tool adds distinct value without unnecessary bloat.
The tool set covers core workflows: listing sources, checking provenance, signing attestations, and planning queries. Minor gaps exist (e.g., no tool to fetch actual tile data, but that's a Pro feature), but for the stated purpose it is largely complete.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
MCP server for Mireye Earth — federal-source-cited geospatial data for any MCP-aware agent.
Geopolitical grounding for AI agents: country risk, forecasts, chokepoints, sanctions. Free tier.
Manage GetIntel AI visibility (GEO) from your own AI agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CSOAI-ORG/gods-eye-geospatial-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
