# GreenlandAI (remote · mcp.greenlandai.ai) GreenlandAI: world graph & map (companies, deposits, commodities), marketplace, wallets, proofs. - Trust score: 66/100 (medium) - Change this week: +2 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-09-29 ## Components - remote · `mcp.greenlandai.ai`: 66/100 (this document), [markdown](https://verifymcp.io/servers/ai-greenlandai-greenlandai/mcp.md), [page](https://verifymcp.io/servers/ai-greenlandai-greenlandai/mcp) ## Channel facts - Endpoint: `https://mcp.greenlandai.ai/mcp` - Transports: `streamable-http` - Auth: `none` - Version: `0.5.12` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-09-29. - **Endpoint Security**: 63/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation not fully verified: no authorisation is required to call this server, and 37 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. - HTTPS is enforced; there's no plaintext access path. - The HSTS (Strict-Transport-Security) header is present. - DNSSEC check failed: this domain isn't protected by DNSSEC. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 57/100 - AI-judged instruction clarity (good). - Context-footprint check failed: tool/resource definitions use about 13211 tokens (~357/item across 37 items; 37 tools + 0 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 48/100 - Stability check failed: schema churn in the 15 days we've observed: 0 tool removals, 1 breaking changes, 0 auth/transport breaks, 7 additions. - **Tool Coverage**: 71/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 0% of tool parameters carry a description. - Structured output schemas are declared (100% of tools); any adoption earns full credit. - **Tool Safety**: 75/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "wallet_transfer" implies "transfer" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. - An AI judge read all 38 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### How do I install the GreenlandAI MCP server? GreenlandAI is a hosted endpoint at https://mcp.greenlandai.ai/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add --transport http ai-greenlandai-greenlandai 'https://mcp.greenlandai.ai/mcp' ``` ### Cursor ```json { "mcpServers": { "ai-greenlandai-greenlandai": { "url": "https://mcp.greenlandai.ai/mcp" } } } ``` ### VS Code ```json { "servers": { "ai-greenlandai-greenlandai": { "type": "http", "url": "https://mcp.greenlandai.ai/mcp" } } } ``` ### Codex ```toml [mcp_servers.ai-greenlandai-greenlandai] url = "https://mcp.greenlandai.ai/mcp" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "ai-greenlandai-greenlandai": { "type": "remote", "url": "https://mcp.greenlandai.ai/mcp", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add ai-greenlandai-greenlandai --url 'https://mcp.greenlandai.ai/mcp' --transport streamable-http ``` ### Hermes ```yaml mcp_servers: ai-greenlandai-greenlandai: url: "https://mcp.greenlandai.ai/mcp" ``` ### Netclaw ```json { "McpServers": { "ai-greenlandai-greenlandai": { "Transport": "http", "Url": "https://mcp.greenlandai.ai/mcp" } } } ``` ### Vellum ```bash assistant mcp add ai-greenlandai-greenlandai -t streamable-http -u 'https://mcp.greenlandai.ai/mcp' ``` ### Other ```json { "mcpServers": { "ai-greenlandai-greenlandai": { "type": "http", "url": "https://mcp.greenlandai.ai/mcp" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-09-28 (score 66, 0) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-09-27 (score 66, +1) - [security] The server rewrote its instructions, which are the text every model session reads - [security] Tool “deposit_status” rewrote its description, which is the text the model reads - [security] Tool “funding_prepare” rewrote its description, which is the text the model reads - [functional] Schema quality: excellent → good - [functional] Server version: 0.5.9+de788f9 → 0.5.13+7bd5faa ### 2026-09-25 (score 65, +1) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-09-24 (score 64, 0) - [security] Tool “market_request” rewrote its description, which is the text the model reads - [security] Tool “trade_settlement” rewrote its description, which is the text the model reads - [functional] Server version: 0.5.7+12c022d → 0.5.8+b088fbc ### 2026-09-23 (score 64, 0) - [security] The server rewrote its instructions, which are the text every model session reads - [security] Tool “billing_attempts” rewrote its description, which is the text the model reads - [security] Tool “billing_quote” rewrote its description, which is the text the model reads - [security] Tool “company” rewrote its description, which is the text the model reads - [security] Tool “deposit” rewrote its description, which is the text the model reads - [security] Tool “deposit_status” rewrote its description, which is the text the model reads - [security] Tool “deposits” rewrote its description, which is the text the model reads - [security] Tool “funding_prepare” rewrote its description, which is the text the model reads - [security] Tool “hops” rewrote its description, which is the text the model reads - [security] Tool “look_at” rewrote its description, which is the text the model reads - [security] Tool “look_from” rewrote its description, which is the text the model reads - [security] Tool “map_viewport” rewrote its description, which is the text the model reads - [security] Tool “nearby” rewrote its description, which is the text the model reads - [security] Tool “relationships” rewrote its description, which is the text the model reads - [security] Tool “trade_settlement” rewrote its description, which is the text the model reads - [functional regression] Schema quality: 282 → 334 - [functional] Server version: 0.5.6+2f56015 → 0.5.7+12c022d ### 2026-09-22 (score 64, 0) - [security regression] Stability: 0.23 → fail - [security] The server rewrote its instructions, which are the text every model session reads - [security] Tool “trade_settlement” rewrote its description, which is the text the model reads - [security] Tool “billing_quote” rewrote its description, which is the text the model reads - [security] Tool “company” rewrote its description, which is the text the model reads - [security] Tool “market_match” rewrote its description, which is the text the model reads - [security] Tool “oracle_assess” rewrote its description, which is the text the model reads - [security] Tool “wallet_transfer” rewrote its description, which is the text the model reads - [security] Tool “funding_prepare” rewrote its description, which is the text the model reads - [functional regression] Schema quality: 8945 → 10447 - [functional regression] Schema quality: 8945 → 10480 - [functional regression] “funding_prepare” dropped the required parameter “wallet_id” - [functional] Server version: 0.5.6+23b1c19 → 0.5.6+2f56015 - [functional] Server version: 0.5.4+08b4c73 → 0.5.6+23b1c19 - [functional] Server version: 5652867 → 0.5.4+08b4c73 - [functional] New tool “deposit” - [functional] New tool “deposits” - [functional] New tool “trade_settlement” - [functional] New tool “deposit_status” ### 2026-09-21 (score 64, +1) No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-20 (score 63, 0) - [security] The server rewrote its instructions, which are the text every model session reads - [security] Tool “company” rewrote its description, which is the text the model reads - [security] Tool “hops” rewrote its description, which is the text the model reads - [security] Tool “look_at” rewrote its description, which is the text the model reads - [security] Tool “look_from” rewrote its description, which is the text the model reads - [security] Tool “map_viewport” rewrote its description, which is the text the model reads - [security] Tool “nearby” rewrote its description, which is the text the model reads - [security] Tool “relationships” rewrote its description, which is the text the model reads - [security] Tool “market_quote” rewrote its description, which is the text the model reads - [functional regression] Schema quality: 229 → 271 - [functional improvement] Tool “balance_proof” now declares an output schema - [functional improvement] Tool “billing_quote” now declares an output schema - [functional improvement] Tool “bridge_proof” now declares an output schema - [functional improvement] Tool “company” now declares an output schema - [functional improvement] Tool “contribute_receipts” now declares an output schema - [functional improvement] Tool “contribute_relations” now declares an output schema - [functional improvement] Tool “contribute_stats” now declares an output schema - [functional improvement] Tool “contribute_submissions” now declares an output schema - [functional improvement] Tool “funding_prepare” now declares an output schema - [functional improvement] Tool “hops” now declares an output schema - [functional improvement] Tool “joules_balance” now declares an output schema - [functional improvement] Tool “joules_deficit” now declares an output schema - [functional improvement] Tool “ledger_verify” now declares an output schema - [functional improvement] Tool “look_at” now declares an output schema - [functional improvement] Tool “look_from” now declares an output schema - [functional improvement] Tool “map_viewport” now declares an output schema - [functional improvement] Tool “mapdata” now declares an output schema - [functional improvement] Tool “market_accept” now declares an output schema - [functional improvement] Tool “market_listings” now declares an output schema - [functional improvement] Tool “market_match” now declares an output schema - [functional improvement] Tool “market_provide” now declares an output schema - [functional improvement] Tool “market_quote” now declares an output schema - [functional improvement] Tool “market_request” now declares an output schema - [functional improvement] Tool “nearby” now declares an output schema - [functional improvement] Tool “oracle_assess” now declares an output schema - [functional improvement] Tool “oracle_assignments” now declares an output schema - [functional improvement] Tool “oracle_deregister” now declares an output schema - [functional improvement] Tool “oracle_register” now declares an output schema - [functional improvement] Tool “relationships” now declares an output schema - [functional improvement] Tool “transparency_latest” now declares an output schema - [functional improvement] Tool “verify_proof” now declares an output schema - [functional improvement] Tool “wallet_transfer” now declares an output schema - [functional] First check of Tool coverage: 100 - [functional] Server version: 0.5.2+c809709 → 5652867 - [functional] Server version: 0.5.1+45336d2 → 0.5.2+c809709 - [functional] New tool “billing_attempts” ## MCP tools (37) ### `look_from` (~746 tokens) Map lane: pins near a point (lat/lng + radius_km). `entity_type` (deposit | infrastructure | company | project) behaves two ways (backend, 2026-09-14): `entity_type` ALONE (with lat/lng) FILTERS the frame to that type only; `entity_type` + `id` ANCHORS the pose at that entity and keeps ALL types; an unknown `entity_type` is a 400 BEFORE any charge (wallet unmoved). Metered — debited from the CALLING agent's own wallet, not the owner's; the response's top-level `charged_joules` is the ALL-IN price (base + 0.5% rail — the same figure as `price.charged_joules`; the `price` block stays as the breakdown). Read the wallet with the `joules_balance` tool. For the exact per-caller price before you call, use the `billing_quote` tool (free, tier-aware; returns `joules_all_in`) or check affordability with the `joules_deficit` tool; the true debit is the base `joule_cost` plus a 0.5% rail surcharge rounded up (a 100 J call debits 101 J) = `joules_all_in`. Results carry `source_tier`/`tier_label` per pin — provenance you should keep. They reflect the pin at read time; a pin's tier or an edge in its `operators` can change afterwards and a held result will not reflect that. `energy=true` includes energy fleet infra; `include_country_centroids=true` adds country-centroid placeholder pins (both off by default). ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `bill… Input parameters: - `energy` (boolean) - `entity_type` - `id` - `include_country_centroids` (boolean) - `lat` - `lng` - `radius_km` (number) ### `relationships` (~763 tokens) Graph lane: labelled relationship EDGES between companies/entities (ownership, operates, supplies, …) — the PRODUCT (edges with tiers + provenance), named for the capability, not the meter. Typed query params (GET /relationships): entity (the START NODE — matched as a case-insensitive SUBSTRING of an entity/company NAME, never an id: "3" matches any name containing "3" and resolves to an arbitrary one, so pass a full, distinctive name), hops (traversal DEPTH 1-10, default 1 — the BILLING UNIT: metered per hop, which is why `billing_quote` takes hops=), relation_type (one relation label, e.g. OPERATES, CONTAINS, MEMBER_OF — checked against the API's allow-list on BOTH paths, with or without `entity`: an unknown label is a 400 naming the allowed set, BEFORE any charge — never an empty 200), search (free-text), limit (<=100, default 50), offset. Metered — debited from the CALLING agent's own wallet, not the owner's (read it with the `joules_balance` tool). For the exact per-caller price before you call, use the `billing_quote` tool (free, tier-aware; returns `joules_all_in`) or check affordability with the `joules_deficit` tool; the true debit is the base `joule_cost` plus a 0.5% rail surcharge rounded up (a 100 J call debits 101 J) = `joules_all_in`. Preserves `source_tier`/`tier_label` on each edge — do not strip them. These reflect the edge at read time; an edge can be demoted afterwards and a held result will not reflect that. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call throu… Input parameters: - `entity` (string) - `hops` (integer) - `limit` (integer) - `offset` (integer) - `relation_type` (string) - `search` (string) ### `hops` (~511 tokens) DEPRECATED alias for `relationships` — kept working, to be removed at a future major. Use `relationships`. Reason (operator ruling 2026-09-14): `hops` names the tool after the BILLING UNIT (traversal depth is what we meter, and `billing_quote` takes hops= for that reason), but the capability is the relationship EDGES with tiers + provenance — a tool list should name the capability, not the meter. Identical behavior and params to `relationships` (incl. an unknown `relation_type` = 400 on both paths, before any charge); also the SDK helper name. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `billing_attempts` tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a top-level `charged_joules` — the all-in PRICE of this call — and a `metering` block written AFTER the settle has run: {attempt_id, settlement, settled_joules, check}. `metering.settlement` is whether you PAID: settled · settled_zero (empty result, nothing moved) · settle_failed (delivered but UNPAID — the wallet is then locked until it clears; the next metered call 402s naming the attempt, the amount and what clears it) · released (4xx/5xx, nothing moved) · unknown. `settled_joules` is what actually left the wallet (0 unless settled). A cached replay carries no block. Input parameters: - `entity` (string) - `hops` (integer) - `limit` (integer) - `offset` (integer) - `relation_type` (string) - `search` (string) ### `nearby` (~574 tokens) Entities near a location (the primitive `look_from` builds on). Typed query params (GET /nearby): lat + lng (required), radius_km (default 100), entity_type (optional filter), limit (<=100, default 20), include_country_centroids (default False). Metered — debited from the CALLING agent's own wallet, not the owner's (read it with the `joules_balance` tool). For the exact per-caller price before you call, use the `billing_quote` tool (free, tier-aware; returns `joules_all_in`) or check affordability with the `joules_deficit` tool; the true debit is the base `joule_cost` plus a 0.5% rail surcharge rounded up (a 100 J call debits 101 J) = `joules_all_in`. Carries `source_tier`/`tier_label`. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `billing_attempts` tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a top-level `charged_joules` — the all-in PRICE of this call — and a `metering` block written AFTER the settle has run: {attempt_id, settlement, settled_joules, check}. `metering.settlement` is whether you PAID: settled · settled_zero (empty result, nothing moved) · settle_failed (delivered but UNPAID — the wallet is then locked until it clears; the next metered call 402s naming the attempt, the amount and what clears it) · released (4xx/5xx, nothing moved) · unknown. `settled_joules` is what actually left… Input parameters: - `entity_type` (string) - `include_country_centroids` (boolean) - `lat` (number, required) - `limit` (integer) - `lng` (number, required) - `radius_km` (number) ### `mapdata` (~211 tokens) CLOSED — do NOT call. `/api/v1/mapdata` (the bulk map-layers surface) is TEMPORARILY closed to ALL callers, agent AND human: the backend returns 403 BEFORE the meter, so NOTHING is charged (GR-109 operator ruling 2026-09-08, gated on AGENT_MAPDATA_ENABLED / HUMAN_MAPDATA_ENABLED — both default off while the map moves to a viewport surface). USE INSTEAD: `map_viewport` for a bounding box (capped pins + counts_by_type) or `look_from` for a pose (pins near a point or anchored on an entity). Kept in the tool list (not removed) so an enumerated list stays stable; reopens metered if the flags flip. (When open it was: metered map dataset, layers + include_country_centroids.) Input parameters: - `include_country_centroids` (boolean) - `layers` (string) ### `map_viewport` (~693 tokens) Map lane: everything inside a bounding box — THE SCREEN (relays GET /api/v1/map.viewport). Typed params: min_lat/min_lng/max_lat/max_lng (the bbox — all four together), entity_type (deposit | infrastructure | company | project — default all four), energy (default False; omits energy fleet infra/projects), include_country_centroids (default False). Returns capped, id-ordered `pins` plus `counts_by_type` — the counts are the TRUE totals for the whole bbox, the pins are a sample, so read counts for totals and pins for detail. AGENT KEYS ONLY (a non-agent credential is refused BEFORE any charge); a per-owner viewport rate window applies; pins do NOT count against your entity cap. Metered — debited from the CALLING agent's own wallet (read it with the `joules_balance` tool); ONE `basic` price per call; quote it with the `billing_quote` tool and the true debit is base + 0.5% rail surcharge = `joules_all_in`. The response carries top-level `charged_joules` (the all-in price — the same figure as `price.charged_joules`; the `price` block stays as the breakdown). Carries `source_tier`/`tier_label` per pin; energy off, pipelines never, centroids off unless asked (same honesty as `look_from`). ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `billing_attempts` tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a… Input parameters: - `energy` (boolean) - `entity_type` - `include_country_centroids` (boolean) - `max_lat` - `max_lng` - `min_lat` - `min_lng` ### `look_at` (~760 tokens) Satellite still of a place — a Sentinel-2 ARCHIVE image (the screen as a picture). Pose = lat/lng OR entity_type+id (anchor); same pose family as `look_from`. Optional `as_of` (YYYY-MM-DD — the newest scene on/before that date) and `max_cloud` (0-100, default 20). AGENT KEYS ONLY (a session/dev key is refused BEFORE any charge). Metered on its own price line — quote it first with `billing_quote("/api/v1/look.at")` — and refunded in full if no image is delivered. RETURNS THE IMAGE (jpeg) as MCP image content PLUS `structuredContent` provenance from the scene's headers — read these and claim nothing stronger: `observed_at` is the SCENE's date, NEVER the request's; `source_tier` is the PROVIDER's, never the pin's; `freshness` is "archive", never "live"; plus cloud_cover, gsd, extent_km, attribution, cache, entity_cap_consumed (0), and the charge: `price_charged_joules` (the all-in price) + `metering_attempt` / `metering_status` — the settle truth for an IMAGE, which has no JSON body to carry a `metering` block (the X-Metering-Status header: completed = paid · settled_zero · settle_failed = delivered but UNPAID · released · cached_replay). A cloudy or MISSING scene returns `available:false` + `freshness:"unavailable"` and is REFUNDED IN FULL — an unavailable RESULT, not an error, and NEVER a fabricated image; that JSON carries top-level `charged_joules` (0 — refunded) and the `metering` block described below. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh… Input parameters: - `as_of` - `entity_type` - `id` - `lat` - `lng` - `max_cloud` (number) ### `company` (~523 tokens) One company's record and graph neighbourhood by id; the response carries `charged_joules` — the all-in PRICE of THIS call (one key on every metered response — the companies/deposits/infrastructure/ projects reads, relationships, and look_from / map_viewport / look_at). Metered — debited from the CALLING agent's own wallet, not the owner's (read it with the `joules_balance` tool). For the exact per-caller price before you call, use the `billing_quote` tool (free, tier-aware; returns `joules_all_in`) or check affordability with the `joules_deficit` tool; the true debit is the base `joule_cost` plus a 0.5% rail surcharge rounded up (a 100 J call debits 101 J) = `joules_all_in`. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with `billing_quote` first; verify any charge with the `billing_attempts` tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a top-level `charged_joules` — the all-in PRICE of this call — and a `metering` block written AFTER the settle has run: {attempt_id, settlement, settled_joules, check}. `metering.settlement` is whether you PAID: settled · settled_zero (empty result, nothing moved) · settle_failed (delivered but UNPAID — the wallet is then locked until it clears; the next metered call 402s naming the attempt, the amount and what clears it) · released (4xx/5xx, nothing moved) · unknown. `settled_joules` is what actually left the wal… Input parameters: - `id` (string, required) ### `deposits` (~452 tokens) Search resource deposits (relays GET /api/v1/deposits). Filters: `commodity`, `resource_type`, `country`, `status`, `owner_country`, `max_port_km`, `search` (name substring), `limit` (<=100), `offset`. ⚠ READ THIS BEFORE USING `commodity`: it filters by the commodity GRAPH, not by the deposit's `resource_type` string. A deposit matches if it CONTAINS the commodity directly, OR CONTAINS a commodity GROUP the commodity is MEMBER_OF. So `commodity="neodymium"` returns EVERY rare-earth-element deposit — including ones whose name and `resource_type` never say "neodymium" (they host the rare_earth_elements group, of which neodymium is a member). That is correct, not a broken filter. The response's top-level `commodity_filter` {query, matched_directly, matched_via_group} tells you which happened — `matched_via_group` names the group (e.g. "rare_earth_elements") when the match came through it. Each deposit carries `commodities[]` ({name, role: primary|byproduct, group}); `resource_type` stays the primary label. Response shape: {count, total, deposits[], commodity_filter, charged_joules, metering}. Metered — `charged_joules` is the all-in PRICE of this call, debited from the CALLING agent's own wallet; `metering.settlement` / `metering.settled_joules` say whether it was actually PAID (settled · settled_zero · settle_failed = delivered but unpaid · released · unknown). Quote first with `billing_quote("/api/v1/deposits")`. Same as the SDK `deposits(commodity=...)`. Input parameters: - `commodity` - `country` - `limit` (integer) - `max_port_km` - `offset` (integer) - `owner_country` - `resource_type` - `search` - `status` ### `deposit` (~181 tokens) One resource deposit's record by numeric id (relays GET /api/v1/deposits/{id}), including its `commodities[]` ({name, role: primary|byproduct, group} — the commodity graph, with `resource_type` as the primary label) and operators. Pair with `deposits(commodity=...)`: search by commodity, then read the deposit. Metered — debited from the CALLING agent's own wallet; the response carries `charged_joules` (the all-in PRICE of this call) and the `metering` block (`metering.settlement` = whether you PAID, `settled_joules` = what left the wallet). Quote with `billing_quote("/api/v1/deposits/{id}")`. Input parameters: - `id` (string, required) ### `market_listings` (~148 tokens) Browse the RAREEAI marketplace: kind="providers" (listings) or "oracles". Typed query params for the providers browse (GET /providers): frontier, resource_type, oracle_verified, active (default True), limit (<=200, default 50), offset, sort (default "price_asc"). Needs a bearer; no write scope to read. Input parameters: - `active` (boolean) - `frontier` (string) - `kind` (string) - `limit` (integer) - `offset` (integer) - `oracle_verified` (boolean) - `resource_type` (string) - `sort` (string) ### `market_match` (~104 tokens) Read one marketplace match by id, including its `escrow_terms` and this trade's typed fee/timeout fields. You must be a party to the match. Bearer required. `dispute_window_end` is populated on oracle-path trades (a real timestamp, not null) — it is the deadline to open a dispute after delivery; for the whole trade's settlement legs use `trade_settlement`. Input parameters: - `match_id` (string, required) ### `market_quote` (~200 tokens) Read one marketplace REQUEST by id (GET /request/{id}; you must own it). Returns the request as the route actually declares it: id, wallet_id, agent_id, frontier, resource_type, unit_type, speed, privacy_mode, contract_escrow, units_needed, max_price_per_unit, priority, requirements, status, units_matched, expires_at, created_at, plus `escrow_terms` — a GENERIC prose block of the escrow rules, identical on every request. It does NOT carry this trade's own figures: `fee_joules`, `escrow_expires_at` and `dispute_window_end` are fields of the MATCH, so read them with `market_match` once a match exists; `buyer_debit_joules` appears only on an x402 price quote (a 402 body). Bearer required. Input parameters: - `request_id` (string, required) Output parameters: - `agent_id` - `contract_escrow` - `created_at` - `escrow_terms`: generic escrow prose; opaque by design - `expires_at` - `frontier` - `id` - `max_price_per_unit` - `priority` - `privacy_mode` - `requirements` - `resource_type` - `speed` - `status` - `unit_type` - `units_matched` - `units_needed` - `wallet_id` ### `joules_balance` (~162 tokens) Your own wallet balance — a FREE read either way (checking costs nothing). A GreenlandAI AGENT key (`gai_`/`gqa_`) reads its OWN wallet via GAI /api/v1/agent/me/balance — NO wallet_id needed; returns {agent_id, agent_name, wallet_id, balance_joules, balance}. A JoulePAI (`jlp_`) or ENYAL (`eyl_`) credential reads by `wallet_id` via JoulePAI /wallet/balance and returns {balance, wallet_id, …}. (The graph/map meter debits this same wallet — this is how an agent checks it before calling.) Input parameters: - `wallet_id` (string) Output parameters: - `agent_id` - `agent_name` - `balance`: spendable joules; the field to act on - `balance_joules`: GAI agent-branch name for the same figure - `handle` - `id`: JoulePAI branch returns the wallet id here - `owner_type` - `verification_status` - `wallet_id` ### `billing_quote` (~308 tokens) The exact per-caller price of a metered call BEFORE you make it — free, no website, an MCP tool you can actually invoke (relays GET /api/v1/billing/quote). `path` = the API path the call would hit — e.g. "/api/v1/relationships" (the `relationships` tool), "/api/v1/look.from" (`look_from`), "/api/v1/map.viewport" (`map_viewport`), "/api/v1/companies/{id}" (`company`), "/api/v1/deposits" (`deposits`), "/api/v1/deposits/{id}" (`deposit`), "/api/v1/nearby" (`nearby`); `hops` = graph depth for a relationships path (an agent key goes to 10 hops — every agent is on one set of terms; a human session to 3). Priced for YOU. Read `joules_all_in` — the TRUE debit (base `joules` + `rail_fee_joules`, the 0.5% rail surcharge); fund that, not the base. Graph paths price per hop and refund unused/empty hops (`refund_on_empty`/`quote_is_maximum`). Bearer required, but NO verification — an unverified caller may still price a call. Input parameters: - `hops` - `path` (string, required) Output parameters: - `billed_hops` - `hops` - `joules`: BASE price, before the rail surcharge - `joules_all_in`: THE TRUE DEBIT — fund this, not `joules` - `partial_refund_note` - `path` - `peg` - `pricing_model` - `pricing_tier` - `query_type` - `quote_is_maximum` - `rail_fee_joules`: the ~0.5% rail surcharge, rounded up - `rate_per_hop` - `refund_on_empty` - `usd` ### `billing_attempts` (~327 tokens) YOUR OWN CHARGE RECORD — what this wallet was charged for, attempt by attempt, so you can verify your bill without asking us (relays GET /api/v1/billing/attempts; own wallet only — derived from your credential, never a parameter). Distinct from `joules_balance` (how much I have): this answers WHAT I WAS CHARGED FOR. Each item: `status` — pending = reserved, not yet settled · completed = settled; `settled_all_in_joules` left the wallet (base + the 0.5% rail fee) · settled_zero = delivered nothing, nothing moved · failed = released, nothing moved (a 4xx, a 5xx, a refused reservation) · settle_failed = delivered but unsettled — new queries refuse until it clears · expired = past the 15-minute replay window, superseded · refunded = reversed in full. `reserved_joules` vs `settled_joules` is the settle-for-delivered difference (partial hops, empty results). Match `attempt_id` to `metering.attempt_id` in the response body you got (or the `X-Metering-Attempt` header / `price.attempt_id`; `look_at`'s image result carries it as `metering_attempt`). `limit` 1-200 (default 50), `offset` for paging. Bearer or agent key required. Input parameters: - `limit` - `offset` Output parameters: - `count` - `items` - `note` - `statuses` - `wallet_id` ### `verify_proof` (~944 tokens) Look up one identifier (chunk_id, proof_id, match_id, transfer id, or a BSV txid) in ENYAL's public verify lookup — no auth. The backend's body is returned UNCHANGED; read these fields, in this order, and claim nothing stronger than they say: - `found:true` = at least one of our systems holds a record for the id. For a chunk, proof or transfer UUID (a DATABASE record; a MATCH is different — see the marketplace-match bullet below): `anchor_status` ∈ {anchored | pending | unanchored} with `bsv_tx_id` — "anchored" means recorded as anchored; the chain is NOT checked on this path; `merkle_proof`/`merkle_root` are present only where the archive stores them. To check the chain, look up the returned `bsv_tx_id`. - For a bare txid (not a match): `chain_status` (confirmed | mempool | not_on_chain | unchecked) and `chain_confirmed` — this 4-value set is the WhatsOnChain status of one transaction and is distinct from a match's `release_anchor_status` enum below; do not conflate the two. Only `chain_confirmed:true` is a verified anchor. `mempool` can still be evicted. `found:false, recorded:true, chain_status:"not_on_chain"` = we recorded it but the network does not have it — a PHANTOM, not an anchor. Coverage (ENYAL as it runs, 2026-09-03): ENYAL's archive, RAREEAI escrow legs (fund/deliver/oracle/release/dispute/resolve/refund) + reputation, JoulePAI transfers + settlement queue; RAREEAI provider-REGISTRATION anchors are outside it. - `degraded:true` (+ `unavailable_sources`) = a source could not be checked; the result is INCONCLUSIVE, not an absence. Only `found:false, degraded:false` is a clean not-found. - For a RAREEAI marketplace match the body carries TWO INDEPENDENT on-chain claims — read both, collapse neither: `ledger_payout_anchor` (the joule movement that settled the trade — provider payout or buyer refund — with its own `txid`/`block_height`/`status`; this… Input parameters: - `identifier` (string, required) Output parameters: - `chain_confirmed`: only true is a verified anchor - `chain_status`: bare-txid lookups: confirmed|mempool|not_on_chain|unchecked - `count` - `degraded`: true = INCONCLUSIVE, never an absence - `found`: a record exists in at least one source - `identifier` - `note` - `recorded`: we hold it even if the chain does not - `results`: per-record verdicts, passed through untouched - `unavailable_sources` ### `ledger_verify` (~39 tokens) Recent public ledger anchors with their on-chain transaction ids and the exact credit supply at each anchor — public, no auth. Independently checkable. Output parameters: - `anchors` - `chain_semantics` - `coverage` - `eras` - `hash_format` - `total` ### `transparency_latest` (~229 tokens) The latest hourly PUBLIC transparency attestation (GET /transparency/latest — no auth): a Merkle root over every wallet balance, the verified total supply, a transaction attestation, the state root, and the Bridge Ledger root, plus the BSV transaction that anchors the batch. ANCHORING IS BATCHED, NEVER IMMEDIATE: five attestations are anchored per OP_RETURN transaction, roughly every five hours. So the newest attestation's top-level `bsv_txid` legitimately reads the string "pending" for up to about five hours after its `timestamp` — that is the normal in-flight state, NOT "unanchored" and NOT an error. `last_anchored` names the most recent attestation whose batch IS on chain and carries a real 64-hex `bsv_txid` (with its merkle_root/bridge_root) you can open on a block explorer; `anchoring` restates the cadence. Everything here is independently checkable — you need not take it on trust. Output parameters: - `algorithm_version` - `anchoring` - `bridge_root` - `bridge_rows` - `bsv_txid`: may read "pending" for ~5h — in-flight, NOT unanchored - `fees` - `last_anchored`: newest attestation actually on chain - `merkle_root` - `settlement_leaves` - `settlement_root` - `state_root` - `supply_verified` - `timestamp` - `total_supply` - `tx_count` - `volume` - `wallet_count` ### `balance_proof` (~175 tokens) Cryptographic inclusion proof for YOUR wallet balance in the latest hourly transparency attestation (GET /wallet/balance-proof): leaf hash, Merkle sibling path, root, the anchoring BSV txid, and `verification` (the steps to recompute the root and check it on chain). Bearer required; the wallet is the one your credential owns — there is NO wallet_id argument, the backend resolves it from your token. Anchoring is batched exactly like transparency_latest: `bsv_txid` may read "pending" until this attestation's OP_RETURN batch (five per transaction, roughly every five hours) is broadcast — not-yet-batched is not unanchored; for the most recent anchored root read transparency_latest.last_anchored. ### `bridge_proof` (~183 tokens) Cryptographic inclusion proofs for YOUR Bridge Ledger rows — contribution/fee events — in the balance-proof shape (GET /programme/bridge/proof): per-row leaf hash, sibling path, the `bridge_root`, and the anchoring BSV txid, plus `verification`. Bearer required; scoped to the holder your token resolves to — no argument. `anchoring` is either "anchored" (with a real 64-hex `bsv_txid`) or a pending note: Bridge rows are anchored by being batched into the hourly transparency attestation (five attestations per OP_RETURN transaction, roughly every five hours), so the newest rows read pending until their batch is broadcast and then carry the batch txid. Nothing is computed on request — it reads what the attestation stored. ### `market_provide` (~174 tokens) Create/update a marketplace listing (POST /provide). Requires marketplace:write (verified account) — an unverified/under-scoped token gets the backend's real 403. First-time provider registration charges a 1,000-joule fee that is SPENT (not a refundable stake — contrast an oracle stake, which is returned on deregister). Body (TYPED — extra fields refused here): {wallet_id, frontier, resource_type, unit_type, price_joules_per_unit (int >=0), capacity_total?, min_units?, max_units_per_match?, endpoint_url?, sla? (dict), speed?, timeout_hours? / timeout_minutes?, stake_amount?, oracle_verified? (opt in to oracle checks), idempotency_key?}. Input parameters: - `body` (required) ### `market_request` (~421 tokens) Post a marketplace BUY request (POST /request) — you want to buy a resource; providers match against it and your escrow is debited on match. Bearer + a verified account (marketplace:write); an under-scoped token gets the backend's real 403. Body (TYPED — extra fields refused here): {wallet_id (a UUID you own, pays escrow), frontier, resource_type, unit_type, units_needed (int >0), max_price_per_unit (int >0, joules), priority?, requirements? (dict), ttl_seconds? (expiry), speed?, privacy_mode?, contract_escrow?, idempotency_key?}. Quote a specific request with `market_quote` before accepting a match. ESCROW LANE: every trade's joules are held in escrow either way. The DEFAULT is the LEDGER LANE — escrow held in a system wallet and settled on the ledger (each settlement leg anchored on chain), NO on-chain contract and no contract fee; the match reads `escrow_bsv_state: "NO_CONTRACT"`, which is the normal, terminal state of that lane, not a failure. Set `contract_escrow: true` to opt in to the on-chain escrow contract lane for a flat contract fee added to your lock; the contract is mandatory for large trades. It takes effect ONLY where an oracle backs the trade (large enough to attract oracle verification, or an oracle-verified provider): a non-oracle opt-in falls back to the ledger lane with no contract and no fee, and the match returns `contract_escrow: false` plus a `contract_note` saying why. Fee and thresholds: https://raree.ai/llms.txt (not restated here). After settlement, `trade_settlement` shows the contract's own legs in its `contract` section (null on a ledger-lane trade). Input parameters: - `body` (required) ### `market_accept` (~60 tokens) Accept a delivery on a match (POST /match/{id}/accept) — releases escrow to the provider. You must be the buyer party; backend enforces it. Input parameters: - `idempotency_key` - `match_id` (string, required) ### `wallet_transfer` (~451 tokens) Direct wallet-to-wallet transfer (POST /wallet/transfer). Requires wallet:transfer scope. WHO CAN SEND (the backend as it runs, 2026-09-03): a verified human wallet to any wallet; an AGENT-class wallet (agent_customer / agent_citizen) ONLY to a REGISTERED destination — either a pending service registration matching {from, to, amount} (a quoted trade or metered charge; pass its registration_id) or the agent's own owner-of-record wallet (a wallet of the same ENYAL account). Any other destination is refused 403 ("Agent wallets cannot transfer to arbitrary destinations…"), relayed verbatim — do NOT retry with another destination. Also refused 403: a settlement-shaped `idempotency_key` (`release|refund|dispute_release|dispute_split::…`) unless the caller is the marketplace service — those keys belong to escrow settlement legs; never mint one, use a fresh opaque key. LIMITS ARE LIVE CONFIG, NOT CONSTANTS: the per-transfer and per-day caps for agent classes are read by the backend on every call from JoulePAI's GET /api/v1/programme/config → wallet_transfer_limits[] (response carries version + config_md5) and change WITHOUT a deploy — read that route before planning a transfer and never plan against a remembered number; verified-human caps are on the JoulePAI docs. A transfer fee is charged to the sender (rate per the JoulePAI docs). A 202 acceptance carries a `bridge` block (units_earned, stream, your_share_bps, standing, config_md5) — keep it. Ineligible callers get the backend's real 403/402/422 verbatim. Body is TYPED to the backend model: {from_wallet_id, to_wallet_id | to_handle, amount, platform?, note?, idempotency_key?, privacy_mode?, include_proof?, registration_id?} — any other field is refused here. Input parameters: - `body` (required) ### `joules_deficit` (~156 tokens) Given a planned `cost`, read a balance and return {needed, have, shortfall, tool_to_call_next} so an agent can decide in-band whether it can afford the next call — no website, no guessing, FREE. A GreenlandAI AGENT key (`gai_`/`gqa_`) reads its OWN balance via GAI /api/v1/agent/me/balance (no wallet_id). A JoulePAI/ENYAL credential reads via JoulePAI — `wallet_id` OPTIONAL (omit → resolved via /wallet/me), pass it for a specific wallet. Input parameters: - `cost` (integer, required) - `wallet_id` (string) Output parameters: - `have` - `needed` - `shortfall`: 0 means affordable now - `tool_to_call_next`: null when nothing is owed ### `funding_prepare` (~202 tokens) The in-band funding step for a joule shortfall — NEVER a website to visit (operator lock). USDC on Base is the live agent-fundable rail: deposit USDC to your own Base address (derived from your credential), at or above the live minimum (`minimum_usdc`, read per call from deposit-status), credited automatically when the deposit scanner sees it — track it with `deposit_status`. Card funding stays a human web flow. Availability is read from the running system per call (relays your deposit-address), so this never reports stale state; it does not itself move money. A GreenlandAI AGENT key (gai_) gets its OWN USDC address (greenlandai.ai/api/v1/agent/me/deposit-address — credits the agent's own wallet) plus its owner's funding route; an owner's developer key is told where its own address is. Input parameters: - `needed` (integer) Output parameters: - `in_band_agent_funding_live` - `needed` - `note` - `routes` - `wallet_id` ### `deposit_status` (~336 tokens) YOUR OWN USDC-on-Base deposit state (relays GET /api/v1/wallet/deposit-status; own wallet only, derived from your credential, never a parameter). States: credited (joules in your wallet) · held_below_min (under `minimum_usdc` — held and accumulated, credits as one entry once your total reaches it; nothing lost) · held_above_max (over the max — held for a human to release; nothing lost) · swept · held_no_fund (the deposit reached the minimum but the platform's funding wallet could not cover the joules at that moment — held, nothing moved, nothing lost; credited AUTOMATICALLY once platform funding is restored — the scanner retries it every minute — no action needed from you). Sent USDC and see nothing yet? Compare your deposit's Base block to scanner_cursor_block: above it = normal lag (the scanner hasn't reached it); at/below it with no row = flagged, not lost. held_below_min / held_above_max / swept / held_no_fund have not yet occurred on real funds. held_inactive (the wallet was not active — closed or frozen — when the deposit arrived; held, nothing credited, released by an operator once it is active again). Bearer or agent key required. A GreenlandAI AGENT key (gai_) reads its own wallet's deposits (greenlandai.ai/api/v1/agent/me/deposit-status); an owner's developer key is told where its own address and status are. Output parameters: - `deposits` - `held_below_min_total_usdc` - `minimum_usdc` - `needed_to_credit_usdc` - `note` - `scanner_cursor_block` - `usdc_live` ### `trade_settlement` (~753 tokens) YOUR OWN trade's settlement — every leg of a marketplace trade you were the BUYER or SELLER of (relays GET /api/v1/wallet/trade/{match_id}/settlement). Party-gated on the backend: a 404 means you were not a party to this match (it also hides whether the match exists at all — never a wallet id leaks). Returns `your_role` (buyer|seller), `settled` (true once the provider has been paid), `leg_count`, and `legs[]` — each leg is {type (provider_payout · oracle_fee · platform_fee · contract_fee · fund_fee · buyer_refund · dispute_refund · dispute_payout · …), recipient_role (a ROLE — provider · oracle · treasury · fee-collection · buyer — NEVER a wallet id; the sentinel "unknown" marks a leg type the backend does not map yet — logged loudly on their side, never money to the platform), amount, status, txid, anchor}, plus top-level `all_anchored` (true only when every leg's anchor is `anchored`). `status` is the LEDGER state of the leg (the money has moved once it reads completed); `txid` is written at BROADCAST, not at confirmation — so a leg can be settled with txid NULL (not broadcast yet — typically under a minute — OR its anchor dead-lettered) or carry a txid not yet on chain. A null txid on a fresh read is NOT a missing or failed leg: read `anchor`, the state to act on — queued | confirming | confirmed → poll (~30 s); anchored → verify the leg's txid on chain yourself (e.g. the `verify_proof` tool with the txid) — you don't have to trust us; failed | cancelled → the ledger leg settled but its anchor dead-lettered and will NOT reach the chain by itself (escalate); none → no anchor was attempted; unknown → a queue state the view does not recognise. This is the trade-WIDE view: `deposit_status` and a single transfer's status show only your own leg, not the payout or fees. Own trades only. Bearer or agent key required. CONTRACT SECTION — top-level `contract`, separate from `legs[]`: the on-chain escr… Input parameters: - `match_id` (string, required) Output parameters: - `all_anchored`: true only when every leg's anchor is 'anchored' - `contract`: the escrow CONTRACT's own chain legs {version, state, closed, closed_on_chain, closing_txid, legs[]}; null = no escrow contract was recorded (a ledger-lane trade) - `leg_count` - `legs` - `match_id` - `settled` - `your_role` ### `oracle_register` (~234 tokens) Register as a RAREEAI oracle by staking joules (POST /oracle/register). INVITE-ONLY at launch (Phase 1 — the oracle pool is operator-run): a non-whitelisted wallet gets a STRUCTURED invite-only response saying how to apply (a verified account, a linked wallet holding the stake, then email info@raree.ai) — the path is discoverable, the gate explicit, no website bounce. Body: {wallet_id (a UUID you own), specialisations (a list of 1 to 7 values from EXACTLY: code, translation, data, general, content, research, infrastructure — any other value is a 422), stake_amount (an integer >= 10000 joules)}. The stake is REFUNDABLE — it is parked in escrow and returned in full when you deregister (unlike a provider listing fee, which is spent). A call overturned on dispute is slashed 10% of the stake. Requires a verified account + marketplace:write. Input parameters: - `body` (required) ### `oracle_assignments` (~131 tokens) List YOUR oracle assignments — the deliveries you have been assigned to assess (GET /oracle/assignments). The backend scopes this to your own wallet; you never see another oracle's queue. Optional query: status (filter) and limit (1-200, default 50). Each assignment carries match_id, deadline (assess within 48 hours or the assignment lapses), fee_earned, and the current verdict/quality if already assessed. Authenticated read — no marketplace:write needed. Input parameters: - `limit` (integer) - `status` (string) ### `oracle_assess` (~344 tokens) Post your verdict on a delivery you were assigned (POST /oracle/assess/{match_id}). Body: {verdict ('valid' or 'invalid'), quality_score (an integer 0-100), notes (<= 2000 chars), and optionally execution_trace (a dict describing how you verified)}. A quality_score below 40 auto-opens a dispute. You earn an equal share of the oracle fee — 1% of the trade value, clamped to 50-5,000 joules total, split evenly across the match's assigned oracles — deducted from the trade at settlement (it comes out of the trade amount before the provider is paid, not a separate platform charge). Assess within the 48-hour deadline. Requires being the assigned oracle + marketplace:write. ⚠ 409 = LATE: the match has already advanced (oracle_status verified/failed/disputed, or the trade has left escrowed/delivered) — your verdict is moot; do NOT retry, read the match instead. Consensus is a MAJORITY of the assigned oracles (floor 2), NOT all-must-report: once a majority lands the trade settles and the remaining assignments EXPIRE (a late assess then 409s). The backend also applies a provider-reputation gate on cold start: a provider with >=3 consecutive failed deliveries and no settled trade is failed automatically; a genuinely new provider (0 settled, <3 fails) is judged neutral. Input parameters: - `body` (required) - `match_id` (string, required) ### `oracle_deregister` (~114 tokens) Deregister as an oracle and unstake (POST /oracle/deregister?wallet_id=...). Returns your staked joules from escrow (less any amount already slashed for overturned calls). Fails if you have pending assessments. wallet_id (the UUID of your oracle wallet) is REQUIRED and is sent as a QUERY parameter (the backend reads it via Query(...), unlike register/assess which take a body). Requires marketplace:write. Input parameters: - `wallet_id` (string, required) ### `contribute_relations` (~438 tokens) Submit evidenced graph relationships to the GreenlandAI contributor door (TEN programme). Auth: your OWN GreenlandAI key in X-API-Key — an agent's gai_ registration key or the owner's gai_ key, the SAME key you use on the graph reads; the agent ID (gqa_) is NOT sent here, the door derives your contributor identity from the key. Contribute must first be enabled on that identity (a one-time human action on greenlandai.ai; the door returns a 403 naming the enable endpoint if it is not). Each item in `relations` MUST carry: subject, relation, object, source_url (a real http(s) page), quote (a verbatim passage >= 15 chars from that page stating the relationship — the judge refutes against it; a missing or placeholder source or quote is rejected at the door). Optional per item: subject_type, object_type. `entities` (optional) proposes a NEW endpoint ONLY alongside a relation that references it — a proposed entity is never accepted on its own. Nothing is written to the graph on submit: admitted claims are QUEUED for the nightly refutation judge (21:15 UTC). Per-item `results[].status`: queued_for_judgement / bundled_with_proposed_entity (queued) · duplicate / already_pending (accepted, not re-counted) · unmapped_relation (vocabulary review, not counted) · unresolved_subject|object (endpoint not found — `suggestions` returned; not counted) · self_loop / source_excluded / invalid (rejected, with reasons). The judge's verdict — promoted, HELD, or dismissed, with its reason — then appears per item via the contribute_submissions tool; the receipt via contribute_receipts; a HELD item is not a failure and is not counted until decided. Standing weights, streams and thresholds are live at GET /api/v1/programme/config — not restated here. Input parameters: - `entities` - `relations` (array, required) ### `contribute_stats` (~91 tokens) Your OWN contributor standing (forward your enabled gai_ key as X-API-Key; the door derives identity from the key). Returns totals (submitted/accepted/rejected), acceptance_rate, pending_review, refused_at_door, standing (good / warning / suspended / revoked) and the thresholds that apply after a floor of submissions. Read-only. GET /api/v1/contribute/status. ### `contribute_submissions` (~135 tokens) Your OWN per-item submission outcomes (forward your enabled gai_ key as X-API-Key). Each item: id, kind, name, outcome (pending_review / accepted / rejected), the judge's reason verbatim in review_note (a pending item reads 'awaiting the judge (nightly, 21:15 UTC)'; a HELD item carries the judge's reason), duplicate flag, promoted {table, id}?, bundle_id?, submitted_at. Read-only. GET /api/v1/contribute/submissions. Input parameters: - `limit` (integer) - `offset` (integer) ### `contribute_receipts` (~100 tokens) Your OWN append-only contribution receipts (forward your enabled gai_ key as X-API-Key) — the proof of what you submitted, with the canonical claim hash (claim_sha256) so you can verify what the door holds matches what you sent. Own rows only, no staff fields. Read-only. GET /api/v1/contribute/receipts. Input parameters: - `limit` (integer) - `offset` (integer) ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/ai-greenlandai-greenlandai/mcp#diagnostics ## Score history - 2026-09-29: 66 - 2026-09-28: 66 - 2026-09-27: 66 - 2026-09-26: 65 - 2026-09-25: 65 - 2026-09-24: 64 - 2026-09-23: 64 - 2026-09-22: 64 - 2026-09-21: 64 - 2026-09-20: 63 - 2026-09-19: 63 - 2026-09-18: 62 - 2026-09-17: 62 - 2026-09-16: 61 - 2026-09-15: 61 - 2026-09-14: 61 ## Common questions ### What is the GreenlandAI MCP server? GreenlandAI is an MCP server listed in the public MCP registry as ai.greenlandai/greenlandai. GreenlandAI: world graph & map (companies, deposits, commodities), marketplace, wallets, proofs. This page covers its hosted endpoint (https://mcp.greenlandai.ai/mcp). ### Is the GreenlandAI MCP server safe to use? GreenlandAI scores 66 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm. ### What tools does the GreenlandAI MCP server expose? GreenlandAI exposes 37 tools: look_from, relationships, hops, nearby, mapdata, and 32 more. Their descriptions and schemas cost roughly 12,373 tokens of context every time the server is loaded. ### Does the GreenlandAI MCP server require authentication? No. We connected to GreenlandAI without credentials and it answered, so anything it exposes is reachable by anyone who knows the address. ### Is the GreenlandAI MCP server still maintained? GreenlandAI is still listed as active in the MCP registry. We last reached this channel on 29 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced. ## Links - Remote endpoint: https://mcp.greenlandai.ai/mcp - Website: https://greenlandai.ai/ - Changelog RSS feed: https://verifymcp.io/servers/ai-greenlandai-greenlandai/mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/ai-greenlandai-greenlandai/mcp.json - HTML version of this page: https://verifymcp.io/servers/ai-greenlandai-greenlandai/mcp