Skip to main content
Glama
sand0vvv

mayan-mcp

by sand0vvv

Build an unsigned Mayan swap transaction

build_swap
Read-only

Construct unsigned Mayan cross-chain swap transactions. Returns quote terms, route, and required approvals for the caller to sign with their own wallet.

Instructions

Build the transaction for a Mayan cross-chain swap and return it UNSIGNED. This server holds no private keys and cannot sign or broadcast — the caller signs with their own wallet. Quote terms (minimum received, slippage, route, ETA) are returned alongside the payload so the signer can see what they are approving. EVM sources also return the ERC20 approval that must be sent first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesHuman-readable amount of the source token, as a decimal string. Example: "0.5".
to_chainYesDestination chain.
to_tokenYesToken symbol (resolved against Mayan's verified token list), an exact token address, or "native".
from_chainYesSource chain — the chain you are spending from.
from_tokenYesToken symbol (resolved against Mayan's verified token list), an exact token address, or "native".
route_typeNoPin a specific route from get_quote. Omitted, the best route is used.
slippage_bpsNoSlippage tolerance in basis points (1 bp = 0.01%). Mayan caps this at 500 (5%). "auto" lets Mayan choose.auto
swapper_addressYesYour address on the source chain. This is the address that will sign.
destination_addressYesRecipient address on the destination chain.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
routeYes
approvalNo
chain_kindYes
custody_noteYes
signer_countYesAlways 0. This server never emits secret material.
verificationYesWhat was actually checked before this payload was released. A field present and false means the check ran and did not hold. A field that is absent means the check does not apply here: the forwarder cross-check reads an EVM call, so it is absent on Solana builds, which are instruction lists with no such envelope.
evm_transactionNo
swapper_addressYes
solana_transactionNo
destination_addressYes
Behavior5/5

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

The description discloses that the tool returns an unsigned transaction and that the server cannot sign or broadcast, aligning with the readOnlyHint annotation (no state modification). It also reveals that quote terms are returned for user review, and that EVM sources require a prior ERC20 approval. This adds significant behavioral context beyond 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 four sentences, front-loaded with the main purpose. Each sentence adds essential information: core action, signing constraint, returned data, and EVM-specific caveat. No redundant or irrelevant text.

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 the comprehensive input schema (100% coverage) and the presence of an output schema (not shown but referenced), the description is complete. It explains the tool's role, return value, caller responsibilities, and cross-chain nuances, leaving no major gaps for a typical swap workflow.

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 each parameter adequately. The description does not add per-parameter meaning beyond the schema, but it does provide overall context that the output includes quote terms and ERC20 approval for EVM. 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 clearly states it builds an unsigned Mayan swap transaction. It specifies the action ('build'), the resource ('swap transaction'), and the key constraint ('unsigned'), distinguishing it from sibling tools like get_quote (which only provides quotes) and track_order (which tracks execution).

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 explains that the server holds no keys and the caller must sign, and mentions the ERC20 approval step for EVM chains. It implies usage after receiving a quote, but does not explicitly state alternatives or when to avoid using this tool. The context is helpful but not exhaustive.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sand0vvv/mayan-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server