GREENLANDAI

wallet_transfer

Destructive

A direct wallet-to-wallet transfer (wallet:transfer scope). An agent wallet may send only to a registered destination; limits are live config, not constants. Typed body: from_wallet_id, to_wallet_id or to_handle, amount and options. A transfer fee is charged to the sender. privacy_mode: only 'transparent' (or omit it) — the other modes are temporarily unavailable and refused.

Input Schema

Name	Required	Description	Default
`body`	Yes	The transfer; each field is described in its schema.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

removedInput schema / $defs / TransferBody / properties / include_proof

Removed value: -{
-  "anyOf": [
-    {
-      "type": "boolean"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "also return the transfer's proof in the response"
-}

changedInput schema / $defs / TransferBody / properties / privacy_mode / description

Previous value: -"the transfer's privacy mode, per the JoulePAI docs"New value: +"only 'transparent' is accepted for now (or omit it): 'confidential', 'private' and 'stark_wrapped' are …"

Changed22 schema fields changedOct 29, 2026
- removedInput schema / $defs / TransferBody / properties / amount / title
```
Removed value: -"Amount"
```
- removedInput schema / $defs / TransferBody / properties / from_wallet_id / title
```
Removed value: -"From Wallet Id"
```
- removedInput schema / $defs / TransferBody / properties / idempotency_key / default
```
Removed value: -null
```
- changedInput schema / $defs / TransferBody / properties / idempotency_key / description
```
Previous value: -"your own opaque key, 1-128 characters: the same key and body is one transfer, never two. Never use a settlement-shaped key (release|refund|dispute_release|dispute_split:<match_id>:…) — those are refused"New value: +"your own opaque key, 1-128 characters: the same key and body is one transfer, never two."
```
- removedInput schema / $defs / TransferBody / properties / idempotency_key / title
```
Removed value: -"Idempotency Key"
```
- removedInput schema / $defs / TransferBody / properties / include_proof / default
```
Removed value: -null
```
- removedInput schema / $defs / TransferBody / properties / include_proof / title
```
Removed value: -"Include Proof"
```
- removedInput schema / $defs / TransferBody / properties / note / default
```
Removed value: -null
```
- removedInput schema / $defs / TransferBody / properties / note / title
```
Removed value: -"Note"
```
- removedInput schema / $defs / TransferBody / properties / platform / default
```
Removed value: -null
```
- removedInput schema / $defs / TransferBody / properties / platform / title
```
Removed value: -"Platform"
```
- removedInput schema / $defs / TransferBody / properties / privacy_mode / default
```
Removed value: -null
```
- removedInput schema / $defs / TransferBody / properties / privacy_mode / title
```
Removed value: -"Privacy Mode"
```
- removedInput schema / $defs / TransferBody / properties / registration_id / default
```
Removed value: -null
```
- removedInput schema / $defs / TransferBody / properties / registration_id / title
```
Removed value: -"Registration Id"
```
- removedInput schema / $defs / TransferBody / properties / to_handle / default
```
Removed value: -null
```
- removedInput schema / $defs / TransferBody / properties / to_handle / title
```
Removed value: -"To Handle"
```
- removedInput schema / $defs / TransferBody / properties / to_wallet_id / default
```
Removed value: -null
```
- removedInput schema / $defs / TransferBody / properties / to_wallet_id / title
```
Removed value: -"To Wallet Id"
```
- removedInput schema / $defs / TransferBody / title
```
Removed value: -"TransferBody"
```
- removedInput schema / title
```
Removed value: -"wallet_transferArguments"
```
- removedOutput schema / title
```
Removed value: -"wallet_transferDictOutput"
```

Changed9 schema fields changedOct 17, 2026

addedInput schema / $defs / TransferBody / properties / amount / description

Added value: +"joules to send, a whole number > 0 (the transfer fee is charged to the sender on top)"

addedInput schema / $defs / TransferBody / properties / idempotency_key / description

Added value: +"your own opaque key, 1-128 characters: the same key and body is one transfer, never two. Never use a settlement-shaped key (release|refund|dispute_release|dispute_split:<match_id>:…) — those are refused"

addedInput schema / $defs / TransferBody / properties / include_proof / description
```
Added value: +"also return the transfer's proof in the response"
```

addedInput schema / $defs / TransferBody / properties / note / description

Added value: +"a note recorded with the transfer, up to 500 characters"

addedInput schema / $defs / TransferBody / properties / platform / description

Added value: +"the platform the transfer is made for, recorded on the transfer"

addedInput schema / $defs / TransferBody / properties / privacy_mode / description
```
Added value: +"the transfer's privacy mode, per the JoulePAI docs"
```
addedInput schema / $defs / TransferBody / properties / to_handle / description
```
Added value: +"recipient handle instead of a wallet id"
```
addedInput schema / $defs / TransferBody / properties / to_wallet_id / description
```
Added value: +"recipient wallet UUID; send this or to_handle"
```

addedInput schema / properties / body / description

Added value: +"The transfer; each field is described in its schema."

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

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

First observedSep 14, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructive=true and readOnly=false, and the description adds real substance beyond them: a fee is charged on top of the amount, limits are dynamic config, destinations must be pre-registered, and non-transparent privacy_mode values are refused at call time. It omits irreversibility of a sent transfer, which would be the one remaining high-value disclosure for a destructive operation.

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?

Four short sentences, scope and precondition front-loaded, no filler. The privacy_mode sentence is somewhat long and could be trimmed now that the schema field carries the same constraint.

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

Completeness4/5

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

An output schema exists, so return values needn't be described, and the parameter schema is fully covered. The description supplies the operational constraints an agent must know before calling. The absence of any note on failure modes or irreversibility is the main residual gap.

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

Parameters3/5

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

Schema description coverage is 100%, so every field including idempotency_key and registration_id is already documented in the schema. The description adds only a summary enumeration of fields and the fee-on-top note, which the amount field also states. Baseline 3 for a fully documented schema.

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

Purpose4/5

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

Opens with a specific verb+resource and scope qualifier ('direct wallet-to-wallet transfer (wallet:transfer scope)'), which separates it from funding-style siblings like deposit. It stops short of naming an alternative sibling, so the differentiation is implicit rather than explicit.

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 concrete preconditions: the sender wallet must be the caller's, an agent wallet may only send to a registered destination, and limits are live config rather than constants. It never explicitly routes the agent to an alternative tool (e.g., deposit for external funding), so it lands at clear-context-without-exclusions.

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?