GreenlandAI

market_request

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?, physical_claim?, idempotency_key?}. Quote a specific request with market_quote before accepting a match. PHYSICAL TRADES: resource_type scene_stack, change_report, site_reconstruction or satellite_imagery MUST carry physical_claim {kind: physical_change|physical_state, site_lat, site_lng, t1, t0 (for a change), radius_m?} — the backend refuses the request without it; the trade is judged against a satellite frame at that site and date. 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 Schema

TableJSON Schema

Name	Required	Description	Default
`body`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 4, 2026

addedInput schema / $defs / PhysicalClaimBody

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "kind": {
+      "description": "physical_change: something changed at the site between t0 and t1 · physical_state: the site shows something at t1",
+      "enum": [
+        "physical_change",
+        "physical_state"
+      ],
+      "title": "Kind",
+      "type": "string"
+    },
+    "radius_m": {
+      "anyOf": [
+        {
+          "maximum": 2500,
+          "minimum": 50,
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Radius M"
+    },
+    "site_entity_id": {
+      "anyOf": [
+        {
+          "maxLength": 64,
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Site Entity Id"
+    },
+    "site_entity_type": {
+      "anyOf": [
+        {
+          "enum": [
+            "deposit",
+            "infrastructure",
+            "company",
+            "project"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Site Entity Type"
+    },
+    "site_lat": {
+      "maximum": 90,
+      "minimum": -90,
+      "title": "Site Lat",
+      "type": "number"
+    },
+    "site_lng": {
+      "maximum": 180,
+      "minimum": -180,
+      "title": "Site Lng",
+      "type": "number"
+    },
+    "t0": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "description": "YYYY-MM-DD; required for physical_change, before t1, on or after 1984-03-16",
+      "title": "T0"
+    },
+    "t1": {
+      "description": "YYYY-MM-DD",
+      "title": "T1",
+      "type": "string"
+    }
+  },
+  "required": [
+    "kind",
+    "site_lat",
+    "site_lng",
+    "t1"
+  ],
+  "title": "PhysicalClaimBody",
+  "type": "object"
+}

addedInput schema / $defs / RequestBody / properties / physical_claim

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/PhysicalClaimBody"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "REQUIRED for resource_type scene_stack, change_report, site_reconstruction or satellite_imagery (refused without it): the site and date the trade is judged against — a satellite frame at that place and time, never a party's word"
+}

Changed1 schema field changedSep 25, 2026

addedInput schema / $defs / RequestBody / properties / contract_escrow

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "opt in to the on-chain escrow contract lane (a flat contract fee added to your lock). Takes effect ONLY where an oracle backs the trade; otherwise the trade falls to the default ledger lane with no contract and no contract fee, and the match says why (contract_escrow=false + contract_note)",
+  "title": "Contract Escrow"
+}

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

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

First observedSep 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: auth model (Bearer + verified account, marketplace:write, real 403 on under-scoped tokens), the side effect (escrow debited on match), typed-body strictness (extra fields refused), and the full escrow-lane behavior including the default ledger lane, the opt-in contract lane, oracle-dependency, and the fallback with contract_note. This is well beyond what structured fields supply.

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?

The purpose and auth/escrow consequences are front-loaded, and every section (body, physical trades, escrow lane) maps to a real decision the caller must make. It is dense and long, but given the tool's complexity the length is mostly earned rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description covers everything else an agent needs: auth/scope, error behavior, the full body contract, physical-claim prerequisites, and escrow-lane outcomes. Nothing required to invoke it correctly is missing.

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

Parameters4/5

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

Schema description coverage is 0% at the top level, so the description must compensate and largely does — it enumerates every body field and gives semantics for the important ones (wallet_id pays escrow, units_needed int >0, max_price_per_unit int >0 in joules, ttl_seconds as expiry). It is docked because several fields (speed, priority, privacy_mode, requirements) are listed with no meaning beyond their names.

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

Purpose5/5

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

States a specific verb and resource ('Post a marketplace BUY request (POST /request)') and immediately clarifies direction: 'you want to buy a resource; providers match against it.' This lets an agent distinguish it from the sell-side sibling market_provide without opening either schema.

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

Usage Guidelines4/5

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

Gives an explicit workflow rule — 'Quote a specific request with market_quote before accepting a match' — naming the sibling and the condition that selects it. It also scopes when physical_claim is mandatory. It stops short of a full when/when-not contrast against market_provide or market_accept, so it is not a 5.

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?