What can you do with this server?

This server provides a read-only interface to Mayan Finance for cross-chain swaps between Solana and EVM chains (Ethereum, Base, Arbitrum, Optimism, Polygon, BSC, Avalanche). It never holds private keys or signs transactions—all payloads are returned unsigned for you to sign in your own wallet. Key capabilities: * Get swap quotes: Retrieve swap routes (SWIFT, FAST_MCTP, MCTP, MONO_CHAIN) with expected output, minimum after slippage, fees, ETA, and price impact. * Build unsigned swaps: Construct unsigned EVM or Solana transactions from a quote, with built-in verification of token, amount, and forwarder contract, plus any required ERC20 approvals. * List tokens: Browse supported tokens by chain, filterable by search and verified status. * Track orders: Check swap status using the source-chain transaction hash. * Check allowances: Read the ERC20 allowance of the Mayan forwarder for a given owner/token and verify it covers a swap amount. * List chains: See supported chains with EVM chain IDs and native token addresses. * Estimate gas: Estimate gas costs for unsigned EVM transactions.

Which integrations are available for this server?

Provides tools for quoting and building unsigned cross-chain swap transactions on the Ethereum blockchain via Mayan Finance. Provides tools for quoting and building unsigned cross-chain swap transactions on the Optimism blockchain via Mayan Finance. Provides tools for quoting and building unsigned cross-chain swap transactions on the Polygon blockchain via Mayan Finance. Provides tools for quoting and building unsigned cross-chain swap transactions on the Solana blockchain via Mayan Finance.

How do I use mayan-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mayan-mcp What would it cost to swap 5 ETH for SOL on Solana?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mayan-mcp

by sand0vvv

Overview Schema Related Servers Score Discussions

TypeScript

Remote

mayan-mcp

An MCP server for Mayan Finance cross-chain swaps.

Ask an AI assistant what a swap will cost, then get the exact transaction to sign — between Solana and seven EVM chains, through Mayan's Swift and MCTP routes.

This server holds no private keys. It cannot sign and it cannot broadcast. build_swap returns an unsigned transaction; the caller signs it in their own wallet. There is no tool here that can move funds.

Every build is cross-checked against its quote before it is returned

Before any transaction is handed over, its own encoded arguments are read back and compared against the quote you were shown — the token, the amount, and the contract it forwards to. A payload that spends more than it quoted is refused rather than returned.

Those are real numbers, not a mockup: scripts/capture-demo.ts drives the built server over stdio against the live API and writes what came back to docs/captured-output.json, which is what the image above renders. Run it yourself and compare — a tool whose claim is "check what you are signing" should be checkable itself.

Custody model


Reads quotes, tokens, swap status	yes
Builds transactions	yes, unsigned
Holds private keys or seed phrases	no
Signs transactions	no
Broadcasts to a chain	no

The guarantee is structural rather than procedural: there is no key material in the process, so there is no code path from a compromised prompt to a moved balance. The signing step belongs to the wallet, which is also where the user sees the recipient address one last time.

Two consequences worth stating plainly:

Tool annotations are not the guarantee. This server sets readOnlyHint, but the MCP specification requires clients to treat annotations from an untrusted server as untrusted. The claim that matters is "no keys in the process", which you can check by reading src/.
A prompt injection cannot move funds through this server, but it can still propose a bad swap. Every response echoes the recipient address, the minimum received and the slippage next to the payload, so the terms are visible before anyone signs.

See SECURITY.md for the threat model, the invariant checks, and a reachability analysis of the current npm audit output.

Related MCP server: Clawswap

Install

Requires Node.js 20 or newer.

npx @sand0vvv/mayan-mcp --help

Claude Desktop / Claude Code

{
  "mcpServers": {
    "mayan": {
      "command": "npx",
      "args": ["-y", "@sand0vvv/mayan-mcp"],
      "env": {
        "SOLANA_RPC_URL": "https://your-solana-rpc-endpoint"
      }
    }
  }
}

Cursor / other MCP clients

Same command, over stdio: npx -y @sand0vvv/mayan-mcp.

Streamable HTTP

npx @sand0vvv/mayan-mcp --http --port 8787

Stateless — a fresh server per request, no session state. It binds to 127.0.0.1 and validates the Host and Origin headers, so a page in your browser cannot reach it by pointing its own hostname at loopback. There is no authentication: exposing it on another interface (--host 0.0.0.0) is a deliberate act that belongs behind a proxy providing auth and rate limiting.

Holding no session state is what MCP's 2026-07-28 revision made mandatory; this server was built that way before it was required. It speaks the protocol versions its SDK implements, which is not yet that revision — the claim is about the property, not the version.

Configuration

Everything comes from the environment. Nothing is required to get a quote.

Variable	Required	Purpose
`SOLANA_RPC_URL`	for Solana builds	Building a Solana-source swap needs a live RPC connection. Without it the server falls back to the public mainnet endpoint, which throttles hard.
`MAYAN_RPC_URL_<CHAIN>`	for allowance reads	Per-chain EVM endpoint, e.g. `MAYAN_RPC_URL_BASE`. Lets the server read your existing allowance instead of assuming an approve is needed. Read-only: the only call made is `eth_call`.
`MAYAN_API_KEY`	no	Lifts Mayan's per-IP rate limit. Request one from `support@mayan.finance`.
`MAYAN_HTTP_TIMEOUT_MS`	no	Default `30000`.
`MAYAN_MAX_RETRIES`	no	Default `3`. Retries are full-jitter backoff, reads only.
`MAYAN_TOKEN_CACHE_TTL_MS`	no	Default `600000`.
`MAYAN_REFERRER_EVM` / `MAYAN_REFERRER_SOLANA`	no	Attaches a fee-split referrer to quotes. Unset by default, and left unset in this project — see SECURITY.md.
`MAYAN_MCP_DEBUG`	no	`1` for verbose logging on stderr.

There is no variable for a private key, and there never will be.

Tools

Tool	What it does
`get_quote`	Every available route for a swap: expected output, guaranteed minimum, slippage, fees, ETA.
`build_swap`	The unsigned transaction, plus the quote terms and any ERC20 approval needed first.
`list_tokens`	Tokens Mayan can route on a chain, with addresses and decimals.
`track_order`	Status of a swap by its source-chain transaction hash.
`check_allowance`	How much the Mayan forwarder is currently allowed to spend, and whether that covers a swap.
`list_chains`	Supported chains and their EVM chain ids.
`estimate_gas`	Gas estimate for a built EVM transaction.

Supported chains: solana, ethereum, base, arbitrum, optimism, polygon, bsc, avalanche.

Worked example

"What do I get for 0.5 SOL into USDC on Base?"

get_quote → two routes:

0.5 SOL on solana -> USDC on base

  SWIFT V2 · Swift
    expected  37.137748 USDC
    minimum   36.933584 USDC  (slippage 55 bps)
    eta       3s
    price     GOOD (ratio 0.9996)
    quote id  0xa4c71a85927b104fe039e05d56efe944

  FAST_MCTP · Best Price
    expected  37.155133 USDC
    minimum   36.954199 USDC  (slippage 50 bps)
    eta       35s
    price     GOOD (ratio 0.9996)

"Build it."

build_swap → the transaction, unsigned:

Unsigned swap built: 10 USDC on base -> SOL on solana via SWIFT

  You receive at least 0.130172143 SOL (expected 0.134198086, slippage 300 bps, ETA 3s)
  Recipient: 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM

  Transaction to sign:
    to       0x337685fdaB40D39bd02028545a4FfA7D287cC3E2
    chainId  8453
    value    0x0
    data     932 bytes (forwardERC20)

  Checked before returning it:
    ok target is the Mayan forwarder from the SDK constant
    ok chain id matches the quote
    ok the call spends USDC, the token quoted
    ok the call spends 10000000 base units, the amount quoted
    ok forwards to 0x40fFE85A28DC9993541449464d7529a922142960, the SWIFT contract the quote declared

  Approval required BEFORE this transaction:
    approve 10000000 (base units) of USDC
    spender 0x337685fdaB40D39bd02028545a4FfA7D287cC3E2   (Mayan forwarder)

  Signers returned: 0. Unsigned. This server holds no private keys and cannot sign or broadcast.

Those checks are not decoration. The transaction is assembled from data Mayan's backend served, so the SDK's own encoded arguments are read back and compared against the quote you were shown: the token, the amount, and the protocol contract. A payload that spends more than it quoted, or routes through a substituted contract, is refused rather than returned. See SECURITY.md.

structuredContent carries the same thing machine-readably: evm_transaction, approval, route and a verification block recording which invariants were checked.

Solana output

Two things are different when the source chain is Solana, both stated here rather than left to be discovered:

The cross-check above does not apply. It reads an EVM call's encoded arguments; a Solana build is a list of instructions with no such envelope. Those fields are therefore absent from the verification block rather than reported as failures. What still holds is the route allow-list and the empty signer set — the custody claim itself. Review the instructions in your wallet.
MCTP from Solana cannot be built here. That route needs an ephemeral keypair to carry its CCTP message, and this server does not emit key material of any kind. SWIFT from Solana builds without one and is what an unpinned build_swap selects.

A Solana-source swap returns instructions in the SDK's own InstructionInfo shape, so the output feeds straight back into deserializeInstructionInfo() without a translation step:

{
  "programId": "ComputeBudget111111111111111111111111111111",
  "accounts": [],
  "data": "AsBcFQA="
}

Address lookup tables come back as base58 addresses, ready for connection.getMultipleAccountsInfo().

What the caller still has to do

Send the approval first on EVM sources, or the swap reverts. build_swap tells you the token, the amount and the spender. With MAYAN_RPC_URL_<CHAIN> set it reads your current allowance and says nothing when you have already approved enough. (USDT on Ethereum additionally requires zeroing an existing allowance before raising it — the response says so when it applies.)
Sign and submit. Not this server's job, by design.
Check the recipient address in your wallet before signing.

Development

npm install
npm run build
npm test          # unit tests: invariants, serialisation round-trip, schemas, layering
npm run typecheck

npx tsx scripts/smoke.ts   # live: quotes and builds against Mayan's API
npx tsx scripts/e2e.ts     # live: spawns the built server and speaks MCP over stdio

The layout keeps one boundary strictly:

src/client/      the only code that talks to @mayanfinance/swap-sdk
src/tools/       MCP tool definitions — Zod in, structuredContent out
src/transport/   stdio and Streamable HTTP

test/layering.test.ts fails the build if anything above src/client imports the SDK or a chain library directly, and it verifies its own detector fires before trusting the result.

License

MIT. See LICENSE.

Not affiliated with Mayan Finance. This is client software for their public API; it makes no warranty about routing, pricing or settlement, and it is not financial advice.

Available Tools

7 tools

build_swapBuild an unsigned Mayan swap transactionA

Read-only

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.

ParametersJSON Schema

Name	Required	Description	Default
`amount`	Yes	Human-readable amount of the source token, as a decimal string. Example: "0.5".
`to_chain`	Yes	Destination chain.
`to_token`	Yes	Token symbol (resolved against Mayan's verified token list), an exact token address, or "native".
`from_chain`	Yes	Source chain — the chain you are spending from.
`from_token`	Yes	Token symbol (resolved against Mayan's verified token list), an exact token address, or "native".
`route_type`	No	Pin a specific route from get_quote. Omitted, the best route is used.
`slippage_bps`	No	Slippage tolerance in basis points (1 bp = 0.01%). Mayan caps this at 500 (5%). "auto" lets Mayan choose.	auto
`swapper_address`	Yes	Your address on the source chain. This is the address that will sign.
`destination_address`	Yes	Recipient address on the destination chain.

Output Schema

ParametersJSON Schema

Name	Required	Description
`route`	Yes
`approval`	No
`chain_kind`	Yes
`custody_note`	Yes
`signer_count`	Yes	Always 0. This server never emits secret material.
`verification`	Yes	What 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_transaction`	No
`swapper_address`	Yes
`solana_transaction`	No
`destination_address`	Yes

TDQS

A4.5/5.0

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.

check_allowanceCheck an ERC20 allowance for the Mayan forwarderA

Read-onlyIdempotent

Read how much of an ERC20 token the Mayan forwarder is currently allowed to spend on someone's behalf, and whether that covers a swap. Read-only: performs an eth_call and nothing else. Requires MAYAN_RPC_URL_ to be configured for the chain.

ParametersJSON Schema

Name	Required	Description
`chain`	Yes	EVM chain the token lives on.
`decimals`	No	Token decimals, purely to render the amounts readably.
`owner_address`	Yes	Address that would be spending the token.
`token_address`	Yes	ERC20 token contract address.
`required_base_units`	No	Amount the swap needs, in base units, to compare against. From build_swap.

Output Schema

ParametersJSON Schema

Name	Required	Description
`chain`	Yes
`owner`	Yes
`spender`	Yes	Always the Mayan forwarder, from the SDK constant.
`sufficient`	Yes	Null when no required amount was given.
`token_address`	Yes
`approve_needed`	Yes
`required_base_units`	Yes
`allowance_base_units`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds that it performs an eth_call and requires MAYAN_RPC_URL_<CHAIN>, providing valuable context beyond the annotations without contradiction.

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, no unnecessary words, front-loaded with core purpose. Every sentence adds value.

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 existence of an output schema and thorough annotations, the description covers the main behavioral aspects (read-only, RPC requirement) and is complete for an agent to decide when and how to invoke the tool.

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%, so baseline is 3. The description adds meaning by explaining that required_base_units comes from build_swap and that owner_address is the spender, enhancing understanding beyond the schema.

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 the tool reads an ERC20 allowance for the Mayan forwarder and checks if it covers a swap. It distinguishes itself from sibling tools (e.g., build_swap, get_quote) by focusing on a read-only allowance check.

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 specifies the tool is read-only and requires RPC URL configuration. While it implies pre-swap usage, it does not explicitly state when not to use it or compare directly with siblings, but the context is clear.

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

estimate_gasEstimate gas for a built EVM swapA

Read-onlyIdempotent

Estimate the gas cost of an unsigned EVM transaction produced by build_swap. Read-only: nothing is signed or sent.

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes	Transaction target — the "to" field from build_swap.
`data`	Yes	Calldata from build_swap.
`from`	Yes	Address that would send the transaction.
`value`	No	Native value as a hex quantity.	0x0
`chain_id`	Yes	EVM chain id from build_swap.
`token_in`	Yes	Address of the input token (zero address for native).

Output Schema

ParametersJSON Schema

Name	Required	Description
`gas_price`	Yes	Gas price in wei, decimal string.
`estimated_gas`	Yes	Gas units, decimal string.
`estimated_fee_wei`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint=false. The description adds 'read-only: nothing is signed or sent' which reinforces annotations but does not reveal new behavioral traits beyond what annotations indicate.

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, front-loaded with purpose, no redundant words. Every sentence adds value: purpose and safety.

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?

With 6 parameters and output schema existing, the description covers core purpose and safety. It could mention that this is for use after build_swap, which it does, but lacks some context like why estimate gas (e.g., to set gas limit). Still adequate.

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 all parameters. The description does not add extra parameter meaning beyond the schema, meeting the baseline for high coverage.

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 the tool estimates gas cost for an unsigned EVM transaction from build_swap, using specific verb and resource. It distinguishes from sibling tools like build_swap which builds transactions.

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 implies usage context: after build_swap produces a transaction. It mentions read-only nature, but does not explicitly state when to use vs. alternatives or what prerequisites are.

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

get_quoteGet a Mayan cross-chain swap quoteA

Read-onlyIdempotent

Quote a cross-chain swap through Mayan Finance. Returns every available route with the expected output, the guaranteed minimum after slippage, fees and ETA. Read-only: this builds nothing and moves nothing.

ParametersJSON Schema

Name	Required	Description	Default
`amount`	Yes	Human-readable amount of the source token, as a decimal string. Example: "0.5".
`to_chain`	Yes	Destination chain.
`to_token`	Yes	Token symbol (resolved against Mayan's verified token list), an exact token address, or "native".
`from_chain`	Yes	Source chain.
`from_token`	Yes	Token symbol (resolved against Mayan's verified token list), an exact token address, or "native".
`slippage_bps`	No	Slippage tolerance in basis points (1 bp = 0.01%). Mayan caps this at 500 (5%). "auto" lets Mayan choose.	auto
`destination_address`	No	Recipient address on the destination chain. Optional, but improves quote accuracy on Solana.

Output Schema

ParametersJSON Schema

Name	Required	Description
`routes`	Yes	Available routes, best first.
`to_token`	Yes
`from_token`	Yes
`route_count`	Yes
`amount_in_base_units`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by confirming read-only nature and detailing the return format (routes, output, minimum after slippage, fees, ETA). This provides transparency beyond structured fields.

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 concise sentences front-load the purpose, followed by return information and safety note. Every sentence adds value with no waste.

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 the complexity (7 parameters, output schema), the description covers the essential purpose, behavior, and return format. It does not mention prerequisites like token availability, but those are implicit and covered by sibling tools.

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 baseline is 3. The description does not add parameter-specific meaning beyond what is in the schema, but it also doesn't need to since the schema is comprehensive.

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 'Quote a cross-chain swap' with a clear verb and resource. It distinctly separates from siblings like build_swap (execution) and list_tokens (token listing), making the tool's unique role obvious.

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 explicitly states 'Read-only: this builds nothing and moves nothing,' which guides the agent to use this for quotations without execution. However, it doesn't explicitly mention when not to use or list alternative tools in the description itself.

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

list_chainsList supported chainsA

Read-onlyIdempotent

List the chains this server can quote and build for, with their EVM chain ids and native token sentinels. Local — makes no network call.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`chains`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds 'makes no network call', which is useful 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?

Two sentences, front-loaded purpose, no wasted words.

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 no parameters, existing output schema, and annotations, the description provides sufficient context about what is returned and that it's local.

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?

No parameters; baseline 4. Description adds no parameter info but schema covers fully.

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?

Description clearly states it lists chains with EVM chain ids and native token sentinels. Distinguishes from siblings which deal with quotes, swaps, tokens, etc.

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?

Implied usage as a discovery tool before quoting/building. 'Local — makes no network call' suggests it's lightweight. No explicit alternatives but context is clear.

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

list_tokensList tokens Mayan can route on a chainA

Read-onlyIdempotent

List the tokens Mayan can route on a given chain, with their addresses and decimals. Use this to find an exact token address when a symbol is ambiguous. Read-only.

ParametersJSON Schema

Name	Required	Description
`chain`	Yes	Chain to list routable tokens for.
`limit`	No
`search`	No	Case-insensitive filter over symbol, name and address.
`verified_only`	No	Keep only tokens Mayan marks as verified. Leave on unless you know why not.

Output Schema

ParametersJSON Schema

Name	Required	Description
`chain`	Yes
`tokens`	Yes
`returned`	Yes
`truncated`	Yes
`total_matching`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description only adds 'Read-only,' which is redundant. No additional behavioral traits beyond annotations are disclosed.

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 with zero waste. The first sentence states the core function, the second adds usage guidance. Well-structured and efficient.

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 the presence of an output schema and strong annotations, the description is complete enough. It covers purpose, usage, and safety (read-only). No obvious gaps.

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 75%, so the schema already documents most parameters. The description does not add meaning beyond the schema; it mentions token addresses and decimals but not parameter specifics. 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 the verb 'List', the resource 'tokens Mayan can route', and the scope 'on a given chain' with additional detail about addresses and decimals. It distinguishes well from siblings like list_chains and check_allowance.

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 provides explicit guidance: 'Use this to find an exact token address when a symbol is ambiguous.' It does not explicitly mention when not to use or name alternatives, but the context makes it clear.

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

track_orderTrack a Mayan swapA

Read-onlyIdempotent

Look up the status of a Mayan swap by its source-chain transaction hash. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`tx_hash`	Yes	Source-chain transaction hash of the swap (EVM 0x… hash or Solana signature).

Output Schema

ParametersJSON Schema

Name	Required	Description
`raw`	Yes	Everything the explorer said about this swap, minus two things that say nothing about it: keys whose value is null, and the logo and block-explorer URLs meant for rendering a web page. No field describing the swap is removed.
`found`	Yes
`status`	No	Mayan lifecycle status, e.g. SETTLED_ON_SOLANA.
`to_amount`	No
`dest_chain`	No
`from_amount`	No
`completed_at`	No
`dest_address`	No
`initiated_at`	No
`source_chain`	No
`to_token_symbol`	No
`from_token_symbol`	No

TDQS

A4.3/5.0

Behavior4/5

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

The description adds 'read-only' which aligns with annotations (readOnlyHint=true, destructiveHint=false). It also specifies the hash type (EVM or Solana), providing extra detail beyond annotations without contradiction.

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 concise sentences, front-loaded with the core action and input, no extraneous information. Every sentence earns 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?

Given the output schema exists and annotations cover safety, the description sufficiently explains input and purpose. It is complete for a simple lookup tool.

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 coverage is 100% and the schema already describes tx_hash in detail. The description does not add additional meaning beyond the schema, so baseline 3 applies.

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 'look up' and resource 'status of a Mayan swap', clearly distinguishing it from siblings like get_quote or build_swap. The input method is also precise ('by its source-chain transaction hash').

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 implies usage when needing the status of a specific swap by transaction hash. It does not explicitly state when not to use or name alternatives, but the sibling list provides context and the purpose is clear enough.

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.

7 tool updatesv0.1.0Jul 27, 2026
- First observedbuild_swap
- First observedcheck_allowance
- First observedestimate_gas
- First observedget_quote
- First observedlist_chains
- First observedlist_tokens
- First observedtrack_order

Install Server

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

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct operation: quoting, building, listing tokens/chains, tracking, gas estimation, and allowance checking. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with underscores (e.g., get_quote, build_swap, list_tokens), making them predictable.

Tool Count5/5

7 tools is well within the ideal range for a focused cross-chain swap server, each tool serving a necessary role without bloat.

Completeness5/5

Covers all essential operations for cross-chain swaps: chain/token discovery, quoting, transaction building, order tracking, gas estimation, and allowance checks. No obvious gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

swaptitan A
net.swaptitan
Non-custodial cross-chain crypto swap MCP — 1288+ assets, no KYC. Solana/EVM/Monero, RPC, oracle.
Cryptocurrency Blockchain Web3 & Decentralized Tech
212
tenzro-lifi A
xyz.tenzro
Li.Fi tools over MCP: cross-chain quotes, routes, execution status, chains, tokens, balances.
Blockchain Cryptocurrency
2
SAP MCP Server B
ai.oobeprotocol.sap.mcp
Solana-native MCP gateway for SAP, DeFi tools, SNS identity, and x402 payments.
Blockchain ERP Systems Payments & Billing
41223
Solana MCP by Vybe A
io.github.vybenetwork
Solana MCP for wallets, trades, markets, PnL, transfers, onchain data, signable swaps and API tools.
Blockchain Cryptocurrency Web3 & Decentralized Tech
521,226

Related MCP Servers

MCP Wallet Signer
Blockchain Web3 & Decentralized Tech Security
nikicat
A
license
Not graded
quality
B
maintenance
Non-custodial MCP server that routes blockchain transactions to your browser wallet (MetaMask, Rabby, etc.) for signing — private keys never leave your browser.
Updated 2 months ago (2026-07-15 22:43 UTC)
2
MIT
Clawswap
Blockchain Cryptocurrency Web3 & Decentralized Tech
WarTech9
A
license
A
quality
D
maintenance
MCP server providing cross-chain swaps between Solana and Base for AI agents paid for via x402 micropayments.
Updated 6 months ago (2026-02-27 06:32 UTC)
3
65
2
MIT
near-hydra-mcp
Blockchain Cryptocurrency Web3 & Decentralized Tech
nikshepsvn
A
license
Not graded
quality
C
maintenance
Enables cross-chain transactions (swap, send, balance) on 10 blockchains from a single NEAR account, designed for AI agents and humans via MCP.
Updated 4 months ago (2026-05-11 19:38 UTC)
6
Apache 2.0
solagent-mcp
Blockchain Cryptocurrency Web3 & Decentralized Tech
warfield2016
A
license
Not graded
quality
D
maintenance
Enables AI agents to interact with the Solana blockchain through MCP, supporting wallet queries, token swaps via Jupiter, token transfers, and market data.
Updated 5 months ago (2026-04-08 06:29 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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