Skip to main content
Glama

GreenlandAI

by ai.greenlandai
OverviewDiscussionsAdmin

wallet_transfer

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:<match_id>:…) 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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "wallet_transferDictOutput",
+  "type": "object"
+}
  2. First observed

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 it discloses a great deal: required wallet:transfer scope, role-based destination rules, live-read limits, fee, 202 bridge block fields, and verbatim backend errors. It even warns against planning on remembered config values and against minting settlement-shaped idempotency keys.

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 text is long, but the complexity of a live-configured, role-restricted money movement endpoint justifies it; the core action and scope appear first. All-caps flags and explicit anti-instructions are dense but purposeful, though tighter formatting would improve scannability.

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?

For a financial write endpoint with no annotations and an opaque body parameter, the description covers auth, eligibility, limits, fees, response payload expectations, and failure behavior. An output schema exists, and the description largely makes the tool safe and correct to call.

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?

Although schema_description_coverage is 0%, the description enumerates the typed body, marks optional fields with ?, and clarifies the to_wallet_id | to_handle alternative and registration_id's role for agent-class quoted transfers. It doesn't deeply explain platform, privacy_mode, and include_proof, but their names and optional markers give reasonable semantic grounding.

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?

The description opens with 'Direct wallet-to-wallet transfer' plus the endpoint POST /wallet/transfer, naming a precise verb, resource, and HTTP operation. This is enough to distinguish it from sibling tools like deposit, market_*, or trade_settlement, even though it doesn't explicitly name them.

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?

It lays out explicit eligibility rules (verified-human vs agent-class), required registration_id for agent-class transfers, and hard 'refused 403' cases with instructions not to retry and to use a fresh opaque key. It doesn't name sibling tools as alternatives, but the when/when-not conditions are concrete and actionable.

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

All GreenlandAI toolsInspect
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