Which integrations are available for this server?

Enables AI agents to perform cross-chain token swaps using NEAR's intent-based architecture and the Defuse Protocol, including token discovery, quote retrieval, swap execution, and status tracking. Allows AI agents to swap tokens to and from Solana via NEAR Intents and the Defuse Protocol, supporting token discovery, quotes, execution, and status tracking for Solana assets.

How do I use near-intent-swaps?

1. Click on "Deploy 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., "@near-intent-swaps What's the rate to swap 100 USDC for SOL?" 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.

near-intent-swaps

by BrainDAO

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

🔗 NEAR Intent Swaps MCP Server

npm version License: MIT

📖 Overview

The NEAR Intent Swaps MCP Server enables AI agents to perform cross-chain token swaps through NEAR's intent-based architecture using the Defuse Protocol one-click SDK. This server provides a comprehensive 5-step flow for discovering tokens, getting quotes, executing swaps, and tracking their status.

By implementing the Model Context Protocol (MCP), this server allows Large Language Models (LLMs) to facilitate cross-chain swaps seamlessly, bridging the gap between AI assistants and decentralized cross-chain infrastructure.

Related MCP server: sui-trader-mcp

✨ Features

Token Discovery: Discover available tokens across multiple blockchains supported by the Defuse Protocol.
Simple Quotes: Get basic swap quotes without requiring addresses - perfect for rate checking.
Full Quotes: Get complete quotes with deposit addresses for executing swaps.
Swap Execution: Submit deposit transaction hashes to execute cross-chain swaps.
Status Tracking: Monitor swap progress and completion status in real-time.

📦 Installation

🚀 Using npx (Recommended)

To use this server without installing it globally:

npx @iqai/mcp-near-intent-swaps

🔧 Build from Source

git clone https://github.com/IQAIcom/mcp-near-intent-swaps.git
cd mcp-near-intent-swaps
pnpm install
pnpm run build

⚡ Running with an MCP Client

Add the following configuration to your MCP client settings (e.g., claude_desktop_config.json).

📋 Minimal Configuration

{
  "mcpServers": {
    "near-intent-swaps": {
      "command": "npx",
      "args": ["-y", "@iqai/mcp-near-intent-swaps"],
      "env": {
        "NEAR_SWAP_JWT_TOKEN": "your-jwt-token-here"
      }
    }
  }
}

⚙️ Advanced Configuration (Local Build)

{
  "mcpServers": {
    "near-intent-swaps": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-near-intent-swaps/dist/index.js"],
      "env": {
        "NEAR_SWAP_JWT_TOKEN": "your-jwt-token-here",
        "NEAR_SWAP_API_URL": "https://1click.chaindefuser.com"
      }
    }
  }
}

🔐 Configuration (Environment Variables)

Variable	Required	Description	Default
`NEAR_SWAP_JWT_TOKEN`	Yes	JWT token for Defuse Protocol API authentication	-
`NEAR_SWAP_API_URL`	No	Custom API endpoint	`https://1click.chaindefuser.com`

💡 Usage Examples

🔍 Token Discovery

"What tokens are available for cross-chain swaps on NEAR?"
"Show me all supported tokens in the Defuse Protocol."
"List available tokens I can swap from Arbitrum to Solana."

📊 Getting Quotes

"What's the rate to swap 100 USDC from Arbitrum to SOL?"
"Get me a quote for swapping ETH to USDC on NEAR."
"How much SOL would I get for 1000 USDC?"

💱 Executing Swaps

"I want to swap 500 USDC from Arbitrum to Solana."
"Help me execute a cross-chain swap with this deposit address."
"I've sent the funds to the deposit address, here's my transaction hash."

📈 Tracking Status

"Check the status of my swap with deposit address 0xabc..."
"Is my cross-chain swap complete?"
"What's the current state of my pending swap?"

🛠️ MCP Tools

`CHECK_NEAR_SWAP_STATUS`

[STEP 5] Check the current execution status of a NEAR intent swap. Returns the swap state (PENDING_DEPOSIT, PROCESSING, SUCCESS, REFUNDED, FAILED, etc.) along with detailed transaction information. Use this to monitor swap progress after initiating the swap, and continue polling until the swap is complete.

Parameter	Type	Required	Description
`depositAddress`	string	✅	The unique deposit address from the quote response - used to track and retrieve the current status of the swap

`EXECUTE_NEAR_SWAP`

[STEP 4] Submit a deposit transaction hash to initiate the swap after sending funds to the deposit address. This notifies the 1Click service that funds have been sent and triggers the swap execution process. Use this after users have sent their funds to the deposit address from the full quote response.

Parameter	Type	Required	Description
`txHash`	string	✅	Transaction hash of your deposit transaction that was sent to the deposit address from the quote
`depositAddress`	string	✅	The deposit address that was provided in the quote response and to which the deposit transaction was sent

`GET_NEAR_SWAP_FULL_QUOTE`

[STEP 2] Get a full quote with deposit address for a NEAR intent swap. This requires recipient and refund addresses and returns a unique deposit address where users can send their funds to initiate the swap. Use this when users are ready to proceed with the swap after checking the simple quote. NOTE: If users provide simple token names (e.g., 'ETH', 'USDC'), first use GET_NEAR_SWAP_TOKENS to discover the exact token IDs required for this API.

Parameter	Type	Required	Default	Description
`swapType`	string		"EXACT_INPUT"	(Optional, defaults to EXACT_INPUT) Whether to use the amount as the output or the input for the basis of the swap: EXACT_INPUT - request output amount for exact input, EXACT_OUTPUT - request output amount for exact output. The refundTo address will always receive excess tokens back even after the swap is complete.
`originAsset`	string	✅		ID of the origin asset (e.g. 'nep141:arb-0xaf88d065e77c8cc2239327c5edb3a432268e5831.omft.near')
`destinationAsset`	string	✅		ID of the destination asset (e.g. 'nep141:sol-5ce3bf3a31af18be40ba30f721101b4341690186.omft.near')
`amount`	string	✅		Amount to swap as the base amount (can be switched to exact input/output using the dedicated flag), denoted in the smallest unit of the specified currency (e.g., wei for ETH)
`recipient`	string	✅		Recipient address. The format should match recipientType.
`recipientType`	string		"DESTINATION_CHAIN"	(Optional, defaults to DESTINATION_CHAIN) Type of recipient address: DESTINATION_CHAIN - assets will be transferred to chain of destinationAsset, INTENTS - assets will be transferred to account inside intents
`refundTo`	string			(Optional) Address for user refund
`refundType`	string		"ORIGIN_CHAIN"	(Optional, defaults to ORIGIN_CHAIN) Type of refund address: ORIGIN_CHAIN - assets will be refunded to refundTo address on the origin chain, INTENTS - assets will be refunded to refundTo intents account
`slippageTolerance`	number		100	(Optional, defaults to 100) Slippage tolerance for the swap. This value is in basis points (1/100th of a percent), e.g. 100 for 1% slippage.
`dry`	boolean		false	(Optional, defaults to false) Flag indicating whether this is a dry run request. If true, the response will NOT contain the following fields: depositAddress, timeWhenInactive, deadline.
`depositType`	string		"ORIGIN_CHAIN"	(Optional, defaults to ORIGIN_CHAIN) Type of the deposit address: ORIGIN_CHAIN - deposit address on the origin chain, INTENTS - account ID inside near intents to which you should transfer assets inside intents
`deadline`	string		"2026-02-10T11:56:58.847Z"	(Optional, defaults to 1 hour from now) Timestamp in ISO format, that identifies when user refund will begin if the swap isn't completed by then. It needs to exceed the time required for the deposit tx to be minted, e.g. for Bitcoin it might require ~1h depending on the gas fees paid.
`referral`	string			(Optional) Referral identifier (lower case only). It will be reflected in the on-chain data and displayed on public analytics platforms.
`quoteWaitingTimeMs`	number		3000	(Optional, defaults to 3000) Time in milliseconds user is willing to wait for quote from relay

`GET_NEAR_SWAP_SIMPLE_QUOTE`

[STEP 1] Get a simple quote for a NEAR intent swap between different chains and assets. This is a dry run that doesn't require any addresses - perfect for users who want to check swap rates and fees before committing to a swap. Use this when users want to explore swap options without providing recipient addresses. NOTE: If users provide simple token names (e.g., 'ETH', 'USDC'), first use GET_NEAR_SWAP_TOKENS to discover the exact token IDs required for this API.

Parameter	Type	Required	Default	Description
`originAsset`	string	✅		ID of the origin asset (e.g. 'nep141:arb-0xaf88d065e77c8cc2239327c5edb3a432268e5831.omft.near')
`destinationAsset`	string	✅		ID of the destination asset (e.g. 'nep141:sol-5ce3bf3a31af18be40ba30f721101b4341690186.omft.near')
`amount`	string	✅		Amount to swap as the base amount, denoted in the smallest unit of the specified currency (e.g., wei for ETH)
`swapType`	string		"EXACT_INPUT"	(Optional, defaults to EXACT_INPUT) Whether to use the amount as input or output for the swap calculation
`slippageTolerance`	number		100	(Optional, defaults to 100) Slippage tolerance in basis points (100 = 1%)
`quoteWaitingTimeMs`	number		3000	(Optional, defaults to 3000) Time in milliseconds to wait for quote from relay

`GET_NEAR_SWAP_TOKENS`

[DISCOVERY] Get a list of tokens currently supported by the 1Click API for NEAR Intents. Returns token metadata including blockchain, contract address, current USD price, symbol, decimals, and price update timestamp. Use this to help users discover available tokens before requesting quotes.

No parameters

👨‍💻 Development

🏗️ Build Project

pnpm run build

👁️ Development Mode (Watch)

pnpm run watch

✅ Linting & Formatting

pnpm run lint
pnpm run format

📁 Project Structure

src/tools/: Individual tool definitions
src/services/: API client and business logic
src/lib/: Shared utilities
src/index.ts: Server entry point

📚 Resources

⚠️ Disclaimer

This project interacts with cross-chain swap infrastructure. Users should exercise caution and verify all transaction details before executing swaps. Cross-chain transactions involve multiple blockchains and carry inherent risks.

📄 License

MIT

Available Tools

5 tools

CHECK_NEAR_SWAP_STATUSA

ParametersJSON Schema

Name	Required	Description	Default
`depositAddress`	Yes	The unique deposit address from the quote response - used to track and retrieve the current status of the swap

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses that the tool returns swap state and transaction info, implying a read-only, non-destructive polling operation. However, it does not explicitly state idempotency, rate limits, or that it doesn't modify state, which could aid agent decision-making.

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 a single sentence followed by a brief usage instruction, front-loading the core purpose. Every sentence adds value, and there is no extraneous information.

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 no output schema and low complexity (1 param, no enums, no nested objects), the description adequately covers the return data (states and transaction info). It could be more explicit about the format of 'detailed transaction information,' but it is sufficient for a status check 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%, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema provides (e.g., 'depositAddress' is explained in both). The tool description reinforces its purpose but does not compensate for missing parameter details.

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 identifies the tool as checking the execution status of a NEAR intent swap, listing specific states (PENDING_DEPOSIT, PROCESSING, SUCCESS, REFUNDED, FAILED) and framing it as step 5 in a sequence, which distinguishes it from sibling tools like EXECUTE_NEAR_SWAP or GET_NEAR_SWAP_FULL_QUOTE.

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 'Use this to monitor swap progress after initiating the swap, and continue polling until the swap is complete,' providing clear when-to-use context. It does not mention when not to use or alternatives, but the context is sufficient for an agent to decide.

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

EXECUTE_NEAR_SWAPA

ParametersJSON Schema

Name	Required	Description	Default
`txHash`	Yes	Transaction hash of your deposit transaction that was sent to the deposit address from the quote
`depositAddress`	Yes	The deposit address that was provided in the quote response and to which the deposit transaction was sent

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must fully convey behavioral traits. It discloses that the tool notifies the 1Click service and triggers swap execution. However, it lacks details on error handling, idempotency, or what happens if the txHash is invalid. Without annotations, this is an acceptable but incomplete disclosure.

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 exceptionally concise: two sentences with no filler. It front-loads the step number and action, and every sentence adds value—purpose, notification mechanism, and usage context.

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 tool's simplicity (2 params, no output schema, no annotations), the description is mostly complete. It covers the purpose, when to use it, and the trigger mechanism. However, it does not mention the return value or error conditions, which would enhance completeness for an agent.

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 input schema already documents both parameters (txHash and depositAddress) with clear descriptions. The tool description does not add any additional parameter semantics beyond the schema. Per guidelines, baseline is 3 when coverage is high.

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's purpose: 'Submit a deposit transaction hash to initiate the swap.' It specifies the action (submit), resource (deposit transaction hash), and outcome (trigger swap execution). This distinguishes it from sibling tools like GET_NEAR_SWAP_FULL_QUOTE and CHECK_NEAR_SWAP_STATUS, which are for quotes and 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 provides explicit usage guidance: 'Use this after users have sent their funds to the deposit address from the full quote response.' It implies a step-by-step process (STEP 4) and clearly indicates when to invoke the tool. However, it does not explicitly mention when not to use it or alternatives.

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

GET_NEAR_SWAP_FULL_QUOTEA

ParametersJSON Schema

Name	Required	Description	Default
`swapType`	No	(Optional, defaults to EXACT_INPUT) Whether to use the amount as the output or the input for the basis of the swap: EXACT_INPUT - request output amount for exact input, EXACT_OUTPUT - request output amount for exact output. The refundTo address will always receive excess tokens back even after the swap is complete.	EXACT_INPUT
`originAsset`	Yes	ID of the origin asset (e.g. 'nep141:arb-0xaf88d065e77c8cc2239327c5edb3a432268e5831.omft.near')
`destinationAsset`	Yes	ID of the destination asset (e.g. 'nep141:sol-5ce3bf3a31af18be40ba30f721101b4341690186.omft.near')
`amount`	Yes	Amount to swap as the base amount (can be switched to exact input/output using the dedicated flag), denoted in the smallest unit of the specified currency (e.g., wei for ETH)
`recipient`	Yes	Recipient address. The format should match recipientType.
`recipientType`	No	(Optional, defaults to DESTINATION_CHAIN) Type of recipient address: DESTINATION_CHAIN - assets will be transferred to chain of destinationAsset, INTENTS - assets will be transferred to account inside intents	DESTINATION_CHAIN
`refundTo`	No	(Optional) Address for user refund
`refundType`	No	(Optional, defaults to ORIGIN_CHAIN) Type of refund address: ORIGIN_CHAIN - assets will be refunded to refundTo address on the origin chain, INTENTS - assets will be refunded to refundTo intents account	ORIGIN_CHAIN
`slippageTolerance`	No	(Optional, defaults to 100) Slippage tolerance for the swap. This value is in basis points (1/100th of a percent), e.g. 100 for 1% slippage.
`dry`	No	(Optional, defaults to false) Flag indicating whether this is a dry run request. If true, the response will NOT contain the following fields: depositAddress, timeWhenInactive, deadline.
`depositType`	No	(Optional, defaults to ORIGIN_CHAIN) Type of the deposit address: ORIGIN_CHAIN - deposit address on the origin chain, INTENTS - account ID inside near intents to which you should transfer assets inside intents	ORIGIN_CHAIN
`deadline`	No	(Optional, defaults to 1 hour from now) Timestamp in ISO format, that identifies when user refund will begin if the swap isn't completed by then. It needs to exceed the time required for the deposit tx to be minted, e.g. for Bitcoin it might require ~1h depending on the gas fees paid.	2026-05-28T01:06:14.489Z
`referral`	No	(Optional) Referral identifier (lower case only). It will be reflected in the on-chain data and displayed on public analytics platforms.
`quoteWaitingTimeMs`	No	(Optional, defaults to 3000) Time in milliseconds user is willing to wait for quote from relay

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full weight. Mentions it returns a unique deposit address and requires recipient/refund addresses. Does not disclose whether the call creates a pending swap or has side effects. The dry run parameter is described in schema but not highlighted in description. Lacks depth on behavioral traits like idempotency or authentication needs.

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?

Four sentences, front-loaded with the main purpose. Uses a clear step label and warns about prerequisite token discovery. Every sentence adds value with no redundancy or filler.

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

Completeness3/5

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

Given 14 parameters and no output schema, the description explains the core workflow but omits details about the return structure beyond 'unique deposit address'. The agent is left to infer other output fields (e.g., estimated output, fees). Lacks completeness for a complex tool with many optional parameters.

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 baseline is 3. The tool description adds context about requiring recipient and refund addresses, but does not elaborate on individual parameters beyond what the schema already provides. The NOTE about token names indirectly helps with originAsset/destinationAsset but does not add new semantic value.

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?

Clearly states the tool gets a full quote with deposit address for a NEAR intent swap. The '[STEP 2]' prefix and mention of checking the simple quote distinguish it from sibling tools like GET_NEAR_SWAP_SIMPLE_QUOTE. The verb 'get' and resource 'full quote' are specific and unambiguous.

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?

States to use this when users are ready to proceed after checking the simple quote. Provides a NOTE directing to GET_NEAR_SWAP_TOKENS for resolving token names. Does not explicitly say when not to use, but the context implies the simple quote is a prerequisite, leaving no ambiguity.

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

GET_NEAR_SWAP_SIMPLE_QUOTEA

ParametersJSON Schema

Name	Required	Description	Default
`originAsset`	Yes	ID of the origin asset (e.g. 'nep141:arb-0xaf88d065e77c8cc2239327c5edb3a432268e5831.omft.near')
`destinationAsset`	Yes	ID of the destination asset (e.g. 'nep141:sol-5ce3bf3a31af18be40ba30f721101b4341690186.omft.near')
`amount`	Yes	Amount to swap as the base amount, denoted in the smallest unit of the specified currency (e.g., wei for ETH)
`swapType`	No	(Optional, defaults to EXACT_INPUT) Whether to use the amount as input or output for the swap calculation	EXACT_INPUT
`slippageTolerance`	No	(Optional, defaults to 100) Slippage tolerance in basis points (100 = 1%)
`quoteWaitingTimeMs`	No	(Optional, defaults to 3000) Time in milliseconds to wait for quote from relay

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the dry-run nature and that no addresses are required, but does not mention any behavioral aspects like rate limits, authentication, or error conditions. It is adequate but not exhaustive.

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?

The description front-loads the purpose and provides structured steps. However, it is slightly verbose with a step number and notes; could be more concise without losing clarity.

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 tool's simplicity and lack of output schema, the description covers purpose, usage hints, and parameter clarifications. It does not explain the return value, but that is acceptable for a simple quote 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%, so baseline is 3. The description restates parameter examples (e.g., originAsset format) and defaults (slippage, wait time) but adds little new meaning beyond the schema. The note about token discovery is helpful context but not parameter-specific.

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 retrieves a simple NEAR intent swap quote as a dry run without needing addresses. It differentiates from siblings by specifying 'simple quote' vs full quote and directing token name discovery to GET_NEAR_SWAP_TOKENS.

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 says to use this when users want to explore swap options without recipient addresses and includes a note to use GET_NEAR_SWAP_TOKENS for simple token names. However, it does not mention when to prefer a full quote or execution over this simple quote.

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

GET_NEAR_SWAP_TOKENSA

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It explains that the tool returns a list of token metadata with specified fields, which is adequate for a read-only discovery tool. However, it does not disclose any potential limitations such as pagination or rate limits.

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 concise with two sentences, front-loaded with a [DISCOVERY] tag. Every word is useful, and there is no redundancy.

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 tool has no parameters and no output schema, the description provides a complete explanation of its purpose, output details, and suggested usage context. It is fully adequate for an agent 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.

Parameters4/5

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

The tool has no parameters, so the input schema is empty with 100% coverage. The description adds no parameter details but explains the output, which is sufficient. Baseline for 0 parameters is 4.

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 identifies the tool as a discovery tool for tokens supported by the NEAR 1Click API. It specifies the exact output (token metadata) and distinguishes itself from sibling tools like CHECK_NEAR_SWAP_STATUS and quote 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 explicitly suggests using this tool before requesting quotes, providing clear context. However, it does not explicitly mention alternatives or when not to use it, though the sibling tools imply different use cases.

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.

5 tool updatesv0.0.12May 28, 2026
- First observedCHECK_NEAR_SWAP_STATUS
- First observedEXECUTE_NEAR_SWAP
- First observedGET_NEAR_SWAP_FULL_QUOTE
- First observedGET_NEAR_SWAP_SIMPLE_QUOTE
- First observedGET_NEAR_SWAP_TOKENS

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-05-28 00:15 across 5 tools

Disambiguation5/5

Each tool has a distinct step in the swap workflow (discovery, simple quote, full quote, execution, status). Descriptions include step numbers, making it impossible to confuse them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with GET_, EXECUTE_, CHECK_ prefixes, all using snake_case and targeting NEAR_SWAP_* entities.

Tool Count5/5

5 tools is well-scoped for the domain: token discovery, two levels of quotes, execution, and status checking. Each tool serves a clear purpose without redundancy.

Completeness4/5

Covers the full swap lifecycle from discovery to status monitoring. Lacks a cancel/refund trigger, but the status tool handles post-swap states adequately.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

paladin-swap A
io.github.paladinfi
Multi-aggregator swap router for AI agents on Base. 10 bps fee. MCP-native, non-custodial.
Blockchain Cryptocurrency
21
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
crypto-defi-mcpOAuth
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2
aeX402 — Cross-Chain DeFi MCP: LINQ, AMM, Bridge, AI A
com.aex402
Agent MCP for DeFi: cross-chain LINQ fan-out, AMM quotes/swaps, bridge, AI. Solana+EVM. Free+x402.
Blockchain Cryptocurrency Web3 & Decentralized Tech
332

Related MCP Servers

uniswap-trader-mcp
Blockchain Web3 & Decentralized Tech
kukapay
A
license
Not graded
quality
F
maintenance
An MCP server for AI agents to automate token swaps on Uniswap DEX across multiple blockchains.
Updated a year ago (2025-05-07 17:23 UTC)
5 npm
39
MIT
sui-trader-mcp
Blockchain Agent Orchestration
kukapay
A
license
Not graded
quality
D
maintenance
An MCP server designed for AI agents to perform optimal token swaps on the Sui blockchain.
Updated a year ago (2025-05-10 08:39 UTC)
6
MIT
orbit-apiofficial
Blockchain Web3 & Decentralized Tech
Orbit-bridge
F
license
Not graded
quality
D
maintenance
MCP server for cross-chain bridging, enabling AI agents to find routes, estimate costs, check risks, execute transfers, and track status across blockchains.
Updated 3 months ago (2026-06-22 12:35 UTC)
-
Uniswap-Trader-MCP
Blockchain Cryptocurrency Web3 & Decentralized Tech
shubhank-saxeena
A
license
Not graded
quality
D
maintenance
An MCP server for AI agents to automate token swaps on Uniswap DEX across multiple blockchains. It provides real-time price quotes, swap execution, and trade suggestions.
Updated a month ago (2026-08-05 01:44 UTC)
5 npm
11
MIT

🔗 NEAR Intent Swaps MCP Server

📖 Overview

✨ Features

📦 Installation

🚀 Using npx (Recommended)

🔧 Build from Source

⚡ Running with an MCP Client

📋 Minimal Configuration

⚙️ Advanced Configuration (Local Build)

🔐 Configuration (Environment Variables)

💡 Usage Examples

🔍 Token Discovery

📊 Getting Quotes

💱 Executing Swaps

📈 Tracking Status

🛠️ MCP Tools

CHECK_NEAR_SWAP_STATUS

EXECUTE_NEAR_SWAP

GET_NEAR_SWAP_FULL_QUOTE

GET_NEAR_SWAP_SIMPLE_QUOTE

GET_NEAR_SWAP_TOKENS

👨‍💻 Development

🏗️ Build Project

👁️ Development Mode (Watch)

✅ Linting & Formatting

📁 Project Structure

📚 Resources

⚠️ Disclaimer

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

orbit-apiofficial

`CHECK_NEAR_SWAP_STATUS`

`EXECUTE_NEAR_SWAP`

`GET_NEAR_SWAP_FULL_QUOTE`

`GET_NEAR_SWAP_SIMPLE_QUOTE`

`GET_NEAR_SWAP_TOKENS`