RAVN

Execute a RAVN swap quote

ravn_execute

Turn a quoteToken from ravn_quote into an execution payload. Returns one of three shapes (executionType): TRANSACTION (sign and broadcast yourself), SIGNATURE (sign, RAVN submits), or DEPOSIT (send the input asset to a given address). RAVN never takes custody of funds — you always sign or send from your own wallet. TRANSACTION and SIGNATURE may also include an approval — an ERC-20 approve() you must broadcast and wait to be MINED before the transaction/signature, or it fails (reverts on TRANSACTION; on SIGNATURE the order is accepted and silently never fills). Only present when the sold token needs it — omitted for native-coin sells and already-approved tokens.

Input Schema

TableJSON Schema

Name	Required	Description
`apiKey`	No	Your RAVN API key, if you have one — raises your rate limit
`quoteToken`	Yes	The quoteToken returned by ravn_quote
`refundAddress`	No	Late-bound refund recipient if the swap fails, for venues that support binding it at execution time. Does NOT apply to a Bitcoin-source Relay or THORChain quote — both fix the refund address at quote time, so this is silently ignored for Relay and rejected outright for THORChain (a mismatch throws rather than executing against a stale address); supply refundAddress on ravn_quote instead
`destinationAddress`	No	Late-bound output recipient, for venues that support binding it at execution time (e.g. NEAR Intents, Garden, Chainflip, Rift). Does NOT apply to Relay, Across, Eco, or THORChain — those fix the recipient at quote time with no execute-time re-bind, so this is silently ignored for them; supply destinationAddress on ravn_quote instead

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 4, 2026

changedInput schema / properties / refundAddress / description

Previous value: -"Late-bound refund recipient if the swap fails, for venues that support binding it at execution time. Does NOT apply to a Bitcoin-source Relay quote — Relay bakes the refund address in at quote time, so this is silently ignored for those; supply refundAddress on ravn_quote instead"New value: +"Late-bound refund recipient if the swap fails, for venues that support binding it at execution time. Does NOT apply to a Bitcoin-source Relay or THORChain quote — both fix the refund address at quote time, so this is silently ignored for Relay and rejected outright for THORChain (a mismatch throws rather than executing against a stale address); supply refundAddress on ravn_quote instead"

Changed1 schema field changedSep 4, 2026

changedInput schema / properties / destinationAddress / description

Previous value: -"Late-bound output recipient, for venues that need it at execution time rather than quote time"New value: +"Late-bound output recipient, for venues that support binding it at execution time (e.g. NEAR Intents, Garden, Chainflip, Rift). Does NOT apply to Relay, Across, Eco, or THORChain — those fix the recipient at quote time with no execute-time re-bind, so this is silently ignored for them; supply destinationAddress on ravn_quote instead"

Changed1 schema field changedSep 4, 2026

changedInput schema / properties / refundAddress / description

Previous value: -"Late-bound refund recipient if the swap fails"New value: +"Late-bound refund recipient if the swap fails, for venues that support binding it at execution time. Does NOT apply to a Bitcoin-source Relay quote — Relay bakes the refund address in at quote time, so this is silently ignored for those; supply refundAddress on ravn_quote instead"

Changed4 schema fields changedSep 3, 2026

addedInput schema / properties / apiKey / description

Added value: +"Your RAVN API key, if you have one — raises your rate limit"

addedInput schema / properties / destinationAddress / description

Added value: +"Late-bound output recipient, for venues that need it at execution time rather than quote time"

addedInput schema / properties / refundAddress / description

Added value: +"Late-bound refund recipient if the swap fails"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "data": {
+          "additionalProperties": false,
+          "properties": {
+            "approval": {
+              "additionalProperties": {},
+              "propertyNames": {
+                "type": "string"
+              },
+              "type": "object"
+            },
+            "approvalData": {
+              "additionalProperties": {},
+              "description": "SIGNATURE only, 0x Gasless: a second EIP-712 payload some venues need signed for the approval itself",
+              "propertyNames": {
+                "type": "string"
+              },
+              "type": "object"
+            },
+            "deposit": {
+              "additionalProperties": {},
+              "description": "DEPOSIT only",
+              "propertyNames": {
+                "type": "string"
+              },
+              "type": "object"
+            },
+            "executionType": {
+              "enum": [
+                "DEPOSIT",
+                "TRANSACTION",
+                "SIGNATURE"
+              ],
+              "type": "string"
+            },
+            "statusRef": {
+              "description": "DEPOSIT only (the deposit address) — SIGNATURE gets its statusRef from submitting to /api/v1/submit-signature instead",
+              "type": "string"
+            },
+            "submit": {
+              "additionalProperties": {},
+              "description": "SIGNATURE only: { url, payload? } — POST the signed payload(s) to ravn_status's ref via /api/v1/submit-signature",
+              "propertyNames": {
+                "type": "string"
+              },
+              "type": "object"
+            },
+            "transaction": {
+              "additionalProperties": {},
+              "description": "TRANSACTION only",
+              "propertyNames": {
+                "type": "string"
+              },
+              "type": "object"
+            },
+            "typedData": {
+              "additionalProperties": {},
+              "description": "SIGNATURE only",
+              "propertyNames": {
+                "type": "string"
+              },
+              "type": "object"
+            }
+          },
+          "required": [
+            "executionType"
+          ],
+          "type": "object"
+        },
+        "meta": {
+          "additionalProperties": false,
+          "properties": {
+            "requestId": {
+              "type": "string"
+            },
+            "version": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "requestId",
+            "version"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "data",
+        "meta"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "error": {
+          "additionalProperties": false,
+          "properties": {
+            "code": {
+              "type": "string"
+            },
+            "details": {},
+            "message": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "code",
+            "message"
+          ],
+          "type": "object"
+        },
+        "meta": {
+          "additionalProperties": false,
+          "properties": {
+            "requestId": {
+              "type": "string"
+            },
+            "version": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "requestId",
+            "version"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "error",
+        "meta"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}

First observedSep 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false), the description adds important execution behavior: RAVN never takes custody, the user must sign or send from their own wallet, and approval must be mined before the transaction or the order can fail or silently never fill. This is exactly the kind of non-obvious failure-mode context that helps an agent act correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences front-load the core purpose and output shapes, then add only the highest-value caveat (approval timing and failure modes). Every sentence earns its place and there is no filler or repetition of schema content.

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?

Given a rich output schema, detailed input schema, and annotations that already signal mutability, the description covers the remaining operational essentials: executionType variants, no-custody rule, approval preconditions, and where late-bound addresses apply. An agent has enough context to select and invoke this tool correctly.

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 the schema already documents quoteToken, apiKey, refundAddress, and destinationAddress in detail, including venue-specific ignore/reject behavior. The description adds little parameter-level meaning beyond tying quoteToken to ravn_quote, so the baseline 3 is appropriate.

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 a specific verb and resource: 'Turn a quoteToken from ravn_quote into an execution payload,' which clearly names the operation and its source. It distinguishes the tool from siblings by focusing on executing quoted swaps and enumerating the three possible executionType shapes, so an agent can separate it from ravn_quote and ravn_status.

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?

The description makes it clear that this tool is the follow-up to ravn_quote ('a quoteToken from ravn_quote'), and it gives actionable guidance on handling TRANSACTION, SIGNATURE, and DEPOSIT results. It does not explicitly list when to avoid the tool or contrast it with ravn_btc_prepare_send, but the prerequisite relationship is strongly implied.

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

All RAVN tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool maps to a distinct lifecycle stage: health, quote, execute, status, and a BTC-specific PSBT preparation helper. ravn_execute and ravn_btc_prepare_send are related but clearly separated, with the latter explicitly scoped as a follow-up for DEPOSIT-type results.

Naming Consistency4/5

All tools share the ravn_ prefix and use lowercase snake_case, which is readable and predictable. However, the naming is not uniformly verb_noun: execute, health, quote, and status are single words, while btc_prepare_send is compound and less symmetrical.

Tool Count5/5

Five tools is well-scoped for this server's purpose. Each tool earns its place, covering quoting, execution, status polling, health checks, and a specialized Bitcoin deposit flow without redundancy.

Completeness5/5

The core quote -> execute -> status lifecycle is fully represented, with health checks for preflight awareness and btc_prepare_send to handle the Bitcoin deposit path. Signing and broadcasting are intentionally left to the user, so there are no dead ends in the server's responsibility.

Execute a RAVN swap quote

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources