A
licenseNot graded
qualityC
maintenanceNon-custodial Solana swap routing with best-price execution, flat 0.25% fee, and built-in on-chain scam checking for token safety.
58
MIT
RAVN
Server Details
Cross-chain swap aggregator across 16+ chains, incl. native Bitcoin/Solana. 0% fees, non-custodial.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ravndex/ravn-examples
- GitHub Stars
- 0
Available Tools
5 toolsravn_btc_prepare_sendPrepare a signable Bitcoin transaction for a RAVN DEPOSITARead-onlyInspect
Turns a DEPOSIT-type ravn_execute result (depositAddress + depositAmount) into a ready-to-sign PSBT, so you don't have to write your own UTXO selection and fee-estimation code. Fetches your UTXOs and the current network fee rate from mempool.space (public, no auth). RAVN never sees or touches a private key — sign the returned PSBT with your own wallet and broadcast it yourself. Only one signer is ever needed (unlike PSBT flows that require coordinating signatures across multiple UTXO-holding wallets), because every RAVN BTC-source venue resolves to a plain single-recipient payment.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Defaults to mainnet | |
| toAddress | Yes | depositAddress from ravn_execute | |
| amountSats | Yes | depositAmount from ravn_execute, in satoshis | |
| fromAddress | Yes | Your Bitcoin address holding the UTXOs to spend — native SegWit (bc1q…) or Taproot (bc1p…) only | |
| feeRateSatsPerVb | No | Omit to use mempool.space's current halfHourFee estimate |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals that the tool fetches UTXOs and the current network fee rate from mempool.space (public, no auth), which is an external behavioral dependency the agent should know. It also discloses that RAVN never sees or touches a private key and that the resulting PSBT needs only one signer, adding meaningful safety and workflow context without contradicting readOnlyHint/openWorldHint.
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?
Three sentences front-load the core transform in the first sentence and then add relevant behavioral context (mempool.space dependency, private-key handling, single-signer nature). There is no filler or tautology, and each sentence contributes useful information for an agent deciding whether to call the tool.
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?
Given that an output schema exists and all parameters are documented, the description covers the workflow, the external service used, the privacy boundary, and the single-signer property. The main purpose and relationship to ravn_execute are explicit, and the sibling tools are clearly distinct. Minor details like error handling or default network behavior are left to the schema, which is acceptable.
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?
All five parameters are fully described in the input schema, so the description does not need to repeat syntax details. The description does helpfully map toAddress and amountSats to the depositAddress and depositAmount fields from ravn_execute, easing correct invocation. This adds value above the schema, but the schema already carries the core parameter semantics.
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 phrase: 'Turns a DEPOSIT-type ravn_execute result ... into a ready-to-sign PSBT,' clearly identifying the resource, the operation, and the output. It names the upstream tool (ravn_execute) and clarifies that this is a preparation step, not the actual broadcast, which distinguishes it from the sibling tools.
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 clearly states when this tool applies: after a DEPOSIT-type ravn_execute result, and why it is useful, because the agent does not need to write its own UTXO selection or fee-estimation code. It also contrasts single-signer PSBT flows with multi-signer coordination, implicitly defining the appropriate context. It does not explicitly enumerate when-not-to-use cases against all siblings, but the sibling names and workflow context make the distinction easy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ravn_executeExecute a RAVN swap quoteAInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
ravn_healthCheck RAVN venue healthARead-onlyInspect
Liveness check across every venue RAVN routes through — call before a swap if you want to know whether a route is degraded ahead of time.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and openWorldHint are already present in annotations, and the description adds behavioral context beyond them: it checks all venues RAVN routes through and is intended as a pre-swap degradation signal. It does not go into response interpretation, but an output schema is present.
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?
A single sentence that front-loads the action and resource, then immediately adds the practical usage trigger. No filler or repetition of structured metadata.
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 zero-parameter, read-only health check with an output schema, the description is fully adequate: it names the scope, the timing, and the purpose. Nothing necessary for an agent to decide to call it 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?
There are zero parameters, so the 0-parameter baseline applies and no parameter documentation is required. The description does not need to add parameter meaning because there is nothing to configure.
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 states a concrete action ('liveness check') and a specific resource ('every venue RAVN routes through'), making the tool's purpose unmistakable. The scope is clearly differentiated from swap execution and quoting siblings by focusing on route/venue health.
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 gives a clear usage context: call before a swap when you want advance knowledge of route degradation. It does not explicitly name alternatives or say when not to use it, so it stops short of full sibling routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ravn_quoteGet a RAVN swap quoteARead-onlyInspect
Get a swap quote from RAVN — same-chain or cross-chain, across 16 chains including native (non-wrapped) Bitcoin and Solana as source or destination. Free, no API key or payment required. Returns a quoteToken; pass it to ravn_execute to get a signable/broadcastable execution payload.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Your RAVN API key, if you have one — raises your rate limit | |
| inputToken | Yes | Token contract address, or 0xEeeeeEeeeEeEeeEeEeEeeeEEeeeeEeeeeeeeEEeE for the chain's native coin | |
| inputAmount | Yes | Positive integer string, in the input token's smallest unit (no decimals) | |
| outputToken | Yes | Token contract address, or 0xEeeeeEeeeEeEeeEeEeEeeeEEeeeeEeeeeeeeEEeE for the chain's native coin | |
| rankingMode | No | best_output (default) picks the highest net output; fastest picks the quickest-settling quote within slippageBps | |
| slippageBps | No | Max acceptable slippage in basis points | |
| userAddress | Yes | Address the input asset will be sent from | |
| inputChainId | Yes | Numeric chain id, e.g. 1=Ethereum, 8453=Base, -1=Bitcoin, -2=Solana — see ravn_health for the live venue list | |
| outputChainId | Yes | Numeric chain id, e.g. 1=Ethereum, 8453=Base, -1=Bitcoin, -2=Solana — see ravn_health for the live venue list | |
| refundAddress | No | Where to refund the input asset if the swap fails. Required here, at quote time, for a Bitcoin-source Relay or THORChain quote — neither has an execute-time re-bind, so omitting it returns a priced-but-unexecutable preview and supplying it later on ravn_execute has no effect. Other BTC-source venues (Garden, Chainflip, Rift) support binding this at execute time instead | |
| destinationAddress | No | Where output should land, if different from userAddress. Required here, at quote time, to get an executable quote from Relay (Bitcoin as the source), THORChain (Bitcoin either direction), Across (a Solana-touching route), or Eco (a cross-ecosystem route) — omit it there and you get back a priced-but-unexecutable preview instead (see ravn_quote's executable), not an error |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses meaningful behavior: the quote is free, requires no API key or payment, and returns a quoteToken rather than a broadcastable transaction. Schema-level notes further reveal that omitting refund or destination addresses on certain venues returns a 'priced-but-unexecutable preview', which is valuable behavioral context. No contradiction with annotations.
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?
The description is three sentences with no filler. It front-loads the core action and scope, then packs in the free/no-key behavior and the crucial quoteToken-to-execute call flow, with each sentence earning its place.
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 an 11-parameter tool with an output schema and rich per-parameter descriptions, the definition is complete: the main description covers scope, cost, output type, and next step, while the schema handles parameter-level specifics like venue-dependent preview behavior and chain id conventions. References to ravn_execute and ravn_health also help route an agent appropriately.
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%, and the parameter descriptions are already rich, with chain id examples, enum meanings, slippage bounds, and venue-specific address caveats. The main description adds little parameter-level detail beyond the quoteToken/execute relationship, so the baseline of 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 leads with a specific verb and resource: 'Get a swap quote from RAVN', then scopes it precisely to same-chain or cross-chain across 16 chains including native Bitcoin and Solana. It also distinguishes itself from ravn_execute by explaining that it returns a quoteToken meant to be passed to that execution tool.
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 clearly places the tool in a workflow: call it to obtain a quoteToken, then pass that token to ravn_execute for an execution payload. It does not explicitly enumerate when not to use it relative to siblings like ravn_btc_prepare_send or ravn_status, but the quote-vs-execute boundary is explicit and the sibling names make the separation reasonably obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ravn_statusCheck RAVN swap statusARead-onlyInspect
Poll the status of a swap by its quoteToken and the ref returned by ravn_execute (deposit address for DEPOSIT venues, statusRef for SIGNATURE venues). Status is authoritative where the venue exposes it; some venues (Rift, Jupiter, Bebop, 0x Gasless) report 'unknown' honestly rather than guessing.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | deposit address (DEPOSIT venues) or statusRef (SIGNATURE venues) from ravn_execute | |
| apiKey | No | Your RAVN API key, if you have one — raises your rate limit | |
| quoteToken | Yes | The quoteToken from ravn_quote — the venue is decoded from it |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given readOnlyHint=true annotations, the description adds meaningful behavioral context: status is authoritative where the venue exposes it, and some named venues honestly return 'unknown' rather than fabricating a guess. This prevents an agent from misinterpreting 'unknown' as a failure or missing status.
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?
Two sentences efficiently convey the action, the required inputs, the source of those inputs, and an important caveat about venue behavior. Every clause earns its place, and the main instruction is front-loaded.
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?
The tool has an output schema, readOnly/openWorld annotations, and complete parameter descriptions, so the description only needs to cover workflow and caveats. It does: where refs come from, how quoteToken is used, and how to interpret 'unknown' from certain venues. Nothing essential 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 coverage is 100%, but the description adds important meaning beyond the schema: ref is a deposit address for DEPOSIT venues and a statusRef for SIGNATURE venues, and quoteToken encodes/decodes the venue. This extra context helps the agent correctly supply non-obvious parameter values.
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 uses a specific verb ('Poll') and clear resource ('status of a swap') with the required inputs (quoteToken and ref). It distinguishes itself from sibling tools like ravn_execute and ravn_quote by framing this as the follow-up status check using values those tools return.
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 clearly states when to use the tool: after ravn_execute, using the returned ref and the quoteToken from ravn_quote. It provides useful venue-specific guidance, but it does not explicitly mention when not to use it or name alternative tools for polling/completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
- Changed
ravn_execute1 field changed- changed
Input schema / properties / refundAddress / descriptionPrevious 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"
- Changed
ravn_quote2 fields changed- changed
Input schema / properties / destinationAddress / descriptionPrevious value: -"Where output should land, if different from userAddress. For a Solana-touching Across quote or a cross-ecosystem Eco quote, this must be supplied here, at quote time — omitting it returns a priced-but-unexecutable preview (see ravn_quote's executable), since neither venue supports fixing the destination after quoting"New value: +"Where output should land, if different from userAddress. Required here, at quote time, to get an executable quote from Relay (Bitcoin as the source), THORChain (Bitcoin either direction), Across (a Solana-touching route), or Eco (a cross-ecosystem route) — omit it there and you get back a priced-but-unexecutable preview instead (see ravn_quote's executable), not an error" - changed
Input schema / properties / refundAddress / descriptionPrevious value: -"Where to refund the input asset if the swap fails. For a Bitcoin-source Relay quote specifically, this must be supplied here, at quote time — Relay has no execute-time re-bind, so omitting it returns a priced-but-unexecutable preview and supplying it later on ravn_execute has no effect. Other BTC-source venues (Garden, THORChain, Chainflip, Rift) support binding this at execute time instead"New value: +"Where to refund the input asset if the swap fails. Required here, at quote time, for a Bitcoin-source Relay or THORChain quote — neither has an execute-time re-bind, so omitting it returns a priced-but-unexecutable preview and supplying it later on ravn_execute has no effect. Other BTC-source venues (Garden, Chainflip, Rift) support binding this at execute time instead"
2 tool updates
- Changed
ravn_execute1 field changed- changed
Input schema / properties / destinationAddress / descriptionPrevious 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"
- Changed
ravn_quote3 fields changed- changed
Input schema / properties / destinationAddress / descriptionPrevious value: -"Where output should land, if different from userAddress"New value: +"Where output should land, if different from userAddress. For a Solana-touching Across quote or a cross-ecosystem Eco quote, this must be supplied here, at quote time — omitting it returns a priced-but-unexecutable preview (see ravn_quote's executable), since neither venue supports fixing the destination after quoting" - changed
Input schema / properties / refundAddress / descriptionPrevious value: -"Where to refund the input asset if the swap fails. For a Bitcoin-source quote this must be supplied here, at quote time — omitting it returns a priced-but-unexecutable preview, and supplying it later on ravn_execute instead has no effect (see ravn_execute's refundAddress)"New value: +"Where to refund the input asset if the swap fails. For a Bitcoin-source Relay quote specifically, this must be supplied here, at quote time — Relay has no execute-time re-bind, so omitting it returns a priced-but-unexecutable preview and supplying it later on ravn_execute has no effect. Other BTC-source venues (Garden, THORChain, Chainflip, Rift) support binding this at execute time instead" - changed
Output schema / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "data": { - "additionalProperties": false, - "properties": { - "approval": { - "additionalProperties": {}, - "description": "Present when the input token needs an ERC-20 approval before executing", - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - "estimatedTimeIsGuess": { - "description": "True when the venue didn't report a time for this quote", - "type": "boolean" - }, - "estimatedTimeSeconds": { - "type": "number" - }, - "expiresAt": { - "type": "number" - }, - "fee": { - "additionalProperties": {}, - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - "gas": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "estimated": { - "type": "boolean" - }, - "native": { - "type": "string" - }, - "nativeSymbol": { - "type": "string" - }, - "usd": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "native", - "nativeSymbol", - "usd", - "estimated" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "The native gas the user must hold; null on gasless venues" - }, - "input": { - "additionalProperties": {}, - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - "output": { - "additionalProperties": {}, - "propertyNames": { - "type": "string" - }, - "type": "object" - }, - "quoteToken": { - "description": "Opaque token — pass to ravn_execute", - "type": "string" - }, - "routeType": { - "type": "string" - }, - "slippage": { - "anyOf": [ - { - "additionalProperties": false, - "properties": { - "bps": { - "type": "number" - }, - "guaranteedMin": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "isFirm": { - "type": "boolean" - } - }, - "required": [ - "bps", - "isFirm", - "guaranteedMin" - ], - "type": "object" - }, - { - "type": "null" - } - ], - "description": "Null when the venue reports no slippage bound" - }, - "venue": { - "additionalProperties": {}, - "propertyNames": { - "type": "string" - }, - "type": "object" - } - }, - "required": [ - "quoteToken", - "venue", - "routeType", - "input", - "output", - "fee", - "slippage", - "gas", - "estimatedTimeSeconds", - "estimatedTimeIsGuess", - "expiresAt" - ], - "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" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "data": { + "additionalProperties": false, + "properties": { + "approval": { + "additionalProperties": {}, + "description": "Present when the input token needs an ERC-20 approval before executing", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "estimatedTimeIsGuess": { + "description": "True when the venue didn't report a time for this quote", + "type": "boolean" + }, + "estimatedTimeSeconds": { + "type": "number" + }, + "executable": { + "description": "False = preview-only price, priced against a placeholder destination/refund address. ravn_execute will fail with QUOTE_NOT_EXECUTABLE — request a fresh quote with destinationAddress/refundAddress supplied instead", + "type": "boolean" + }, + "expiresAt": { + "type": "number" + }, + "fee": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "gas": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "estimated": { + "type": "boolean" + }, + "native": { + "type": "string" + }, + "nativeSymbol": { + "type": "string" + }, + "usd": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "native", + "nativeSymbol", + "usd", + "estimated" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The native gas the user must hold; null on gasless venues" + }, + "input": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "output": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "quoteToken": { + "description": "Opaque token — pass to ravn_execute", + "type": "string" + }, + "routeType": { + "type": "string" + }, + "slippage": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "bps": { + "type": "number" + }, + "guaranteedMin": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "isFirm": { + "type": "boolean" + } + }, + "required": [ + "bps", + "isFirm", + "guaranteedMin" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Null when the venue reports no slippage bound" + }, + "venue": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "required": [ + "quoteToken", + "venue", + "routeType", + "input", + "output", + "fee", + "executable", + "slippage", + "gas", + "estimatedTimeSeconds", + "estimatedTimeIsGuess", + "expiresAt" + ], + "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" + } +]
2 tool updates
- Changed
ravn_execute1 field changed- changed
Input schema / properties / refundAddress / descriptionPrevious 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"
- Changed
ravn_quote1 field changed- changed
Input schema / properties / refundAddress / descriptionPrevious value: -"Where to refund the input asset if the swap fails — defaults to userAddress"New value: +"Where to refund the input asset if the swap fails. For a Bitcoin-source quote this must be supplied here, at quote time — omitting it returns a priced-but-unexecutable preview, and supplying it later on ravn_execute instead has no effect (see ravn_execute's refundAddress)"
5 tool updates
- Changed
ravn_btc_prepare_send2 fields changed- added
Input schema / properties / network / descriptionAdded value: +"Defaults to mainnet" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "error": { + "type": "string" + } + }, + "required": [ + "error" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "changeSats": { + "type": "string" + }, + "estimatedFeeSats": { + "type": "string" + }, + "feeRateSatsPerVb": { + "type": "number" + }, + "inputCount": { + "type": "number" + }, + "psbtBase64": { + "type": "string" + }, + "totalInputSats": { + "type": "string" + } + }, + "required": [ + "psbtBase64", + "inputCount", + "totalInputSats", + "feeRateSatsPerVb", + "estimatedFeeSats", + "changeSats" + ], + "type": "object" + } + ], + "type": "object" +}
- Changed
ravn_execute4 fields changed- added
Input schema / properties / apiKey / descriptionAdded value: +"Your RAVN API key, if you have one — raises your rate limit" - added
Input schema / properties / destinationAddress / descriptionAdded value: +"Late-bound output recipient, for venues that need it at execution time rather than quote time" - added
Input schema / properties / refundAddress / descriptionAdded value: +"Late-bound refund recipient if the swap fails" - changed
Output 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" +}
- Changed
ravn_health1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "data": { + "additionalProperties": false, + "properties": { + "status": { + "enum": [ + "ok", + "degraded" + ], + "type": "string" + }, + "venues": { + "items": { + "additionalProperties": false, + "properties": { + "healthy": { + "type": "boolean" + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "healthy" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "status", + "venues" + ], + "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" +}
- Changed
ravn_quote4 fields changed- added
Input schema / properties / rankingMode / descriptionAdded value: +"best_output (default) picks the highest net output; fastest picks the quickest-settling quote within slippageBps" - added
Input schema / properties / refundAddress / descriptionAdded value: +"Where to refund the input asset if the swap fails — defaults to userAddress" - added
Input schema / properties / slippageBps / descriptionAdded value: +"Max acceptable slippage in basis points" - changed
Output 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": {}, + "description": "Present when the input token needs an ERC-20 approval before executing", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "estimatedTimeIsGuess": { + "description": "True when the venue didn't report a time for this quote", + "type": "boolean" + }, + "estimatedTimeSeconds": { + "type": "number" + }, + "expiresAt": { + "type": "number" + }, + "fee": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "gas": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "estimated": { + "type": "boolean" + }, + "native": { + "type": "string" + }, + "nativeSymbol": { + "type": "string" + }, + "usd": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "native", + "nativeSymbol", + "usd", + "estimated" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The native gas the user must hold; null on gasless venues" + }, + "input": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "output": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "quoteToken": { + "description": "Opaque token — pass to ravn_execute", + "type": "string" + }, + "routeType": { + "type": "string" + }, + "slippage": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "bps": { + "type": "number" + }, + "guaranteedMin": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "isFirm": { + "type": "boolean" + } + }, + "required": [ + "bps", + "isFirm", + "guaranteedMin" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Null when the venue reports no slippage bound" + }, + "venue": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "required": [ + "quoteToken", + "venue", + "routeType", + "input", + "output", + "fee", + "slippage", + "gas", + "estimatedTimeSeconds", + "estimatedTimeIsGuess", + "expiresAt" + ], + "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" +}
- Changed
ravn_status3 fields changed- added
Input schema / properties / apiKey / descriptionAdded value: +"Your RAVN API key, if you have one — raises your rate limit" - added
Input schema / properties / quoteToken / descriptionAdded value: +"The quoteToken from ravn_quote — the venue is decoded from it" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "data": { + "additionalProperties": false, + "properties": { + "status": { + "type": "string" + }, + "tracking": { + "const": "unavailable", + "description": "Present instead of venueStatus when this venue has no live tracker yet", + "type": "string" + }, + "venue": { + "type": "string" + }, + "venueStatus": { + "type": "string" + } + }, + "required": [ + "status", + "venue" + ], + "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" +}
5 tool updates
- First observed
ravn_btc_prepare_send - First observed
ravn_execute - First observed
ravn_health - First observed
ravn_quote - First observed
ravn_status
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Native cross-chain swaps: Bitcoin, Ethereum, Solana, Polkadot, Tron, Arbitrum. Quote, swap, track.
Quote, create and track cross-chain crypto swaps. Non-custodial exchange, no account, no KYC.
Non-custodial cross-chain crypto swap MCP — 1288+ assets, no KYC. Solana/EVM/Monero, RPC, oracle.
Non-custodial value router: ranked fiat/crypto & cross-chain routes, swaps, onramp, gasless wallet.
Related MCP Servers
deBridgeofficial
AlicenseAqualityCmaintenancedeBridge MCP finds optimal cross-chain swap routes, check fees and conditions, and initiate non-custodial trades across major blockchain networks. Supported: Ethereum, Solana, Arbitrum, Base, BNB Chain, Polygon, Optimism, Avalanche, Linea, Berachain, Tron, Cronos, Gnosis, Monad, Sonic, Flow, HyperEVM, Sei, Story, Injective, Abstract, MegaETH, Mantle, Plasma, Zilliqa, Sophon, Bob, Neon, and more58932MIT- AlicenseNot gradedqualityDmaintenanceCross-chain cryptocurrency swaps via Chainflip. Get quotes, execute swaps, and track progress. No API key required to get started.10MIT
- AlicenseNot gradedqualityCmaintenanceDeFi execution layer for AI agents - swap, zap in/out of LP, route across AMMs on 5 EVM chains.1647MIT
Try in Browser
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.