The OpenOcean MCP server enables decentralized token swaps across multiple blockchain networks via OpenOcean's DEX aggregation API. It provides the following capabilities:
Fetch supported chains: Get a list of all available blockchain networks
View available tokens: Retrieve tradeable tokens for a specified chain (defaults to Fraxtal)
Browse DEX exchanges: Get decentralized exchanges available on a specific chain
Check gas prices: Fetch current gas prices for transactions on a given network
Get swap quotes: Request price quotes for token swaps with customizable slippage (0.05-50%, default 1%)
Build swap transactions: Generate transaction data for executing swaps with specified parameters including inTokenAddress, outTokenAddress, amount (with decimals), account (wallet address), and optional slippage
Track transactions: Retrieve transaction details and status using transaction hashes
The server is compatible with MCP clients like AI assistants and IDE extensions, enabling programmatic access to DeFi functionality for comparing rates across DEXs, executing swaps, and monitoring transaction costs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenOcean MCP get a quote to swap 1 ETH for USDC on Ethereum with 1% slippage"
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.
An MCP server for executing token swaps across multiple decentralized exchanges using OpenOcean's aggregation API.
This project implements a Model Context Protocol (MCP) server to interact with decentralized exchanges (DEXs). It allows MCP-compatible clients (like AI assistants, IDE extensions, or custom applications) to access functionalities such as getting quotes for swaps and executing swaps across multiple chains.
This server is built using TypeScript and fastmcp.
Related MCP server: deBridge MCP Server
The server exposes the following tools that MCP clients can utilize:
CHAIN_LIST: Fetch chain list.
Parameters:
GAS_PRICE: Fetch gas price.
Parameters: chain (string)
QUOTE: Fetch a quote for a swap.
Parameters: chain (string), inTokenAddress (string), outTokenAddress (string), amount (string), slippage (string)
SWAP: Building swap transaction.
Parameters: chain (string), inTokenAddress (string), outTokenAddress (string), amount (string), slippage (string), account (string)
GET_TRANSACTION: Fetch transaction info.
Parameters: chain (string), hash (string)
TOKEN_LIST: Fetch token list.
Parameters: chain (string)
DEX_LIST: Fetch dex list.
Parameters: chain (string)
chain: The chain code of the DEX.
inTokenAddress: The token you want to sell.
outTokenAddress: The token you want to buy.
amount: Token amount with decimals. For example, if 1 USDT is input, use 1000000 (1 USDT * 10^6).
slippage: Define the acceptable slippage level by inputting a percentage value within the range of 0.05 to 50. 1% slippage set as 1.
account: user's wallet address.
hash: Hash from the OpenOcean contract on the blockchain.
Node.js (v18 or newer recommended)
pnpm (See https://pnpm.io/installation)
There are a few ways to use openocean-mcp:
1. Using pnpm dlx (Recommended for most MCP client setups):
You can run the server directly using pnpm dlx without needing a global installation. This is often the easiest way to integrate with MCP clients. See the "Running the Server with an MCP Client" section for examples.
(pnpm dlx is pnpm's equivalent of npx)
2. Global Installation from npm (via pnpm):
Install the package globally to make the openocean-mcp command available system-wide:
pnpm add -g openocean-mcp3. Building from Source (for development or custom modifications):
Clone the repository:
git clone https://github.com/openocean-finance/openocean-mcp.git
cd openocean-mcpInstall dependencies:
pnpm installBuild the server:
This compiles the TypeScript code to JavaScript in the dist directory.
pnpm run buildThe prepare script also runs pnpm run build, so dependencies are built upon installation if you clone and run pnpm install.
This MCP server may require certain environment variables to be set by the MCP client that runs it. These are typically configured in the client's MCP server definition (e.g., in a mcp.json file for Cursor, or similar for other clients).
Any necessary environment variables for wallet providers or API keys.
MCP clients (like AI assistants, IDE extensions, etc.) will run this server as a background process. You need to configure the client to tell it how to start your server.
Below is an example configuration snippet that an MCP client might use (e.g., in a mcp_servers.json or similar configuration file). This example shows how to run the server using the published npm package via pnpm dlx.
{
"mcpServers": {
"openocean-mcp-server": {
"command": "pnpm",
"args": ["dlx", "openocean-mcp"]
}
}
}Alternative if Globally Installed:
If you have installed openocean-mcp globally (pnpm add -g openocean-mcp), you can simplify the command and args:
{
"mcpServers": {
"openocean-mcp-server": {
"command": "openocean-mcp",
"args": []
}
}
}command: The executable to run.
For pnpm dlx: "pnpm" (with "dlx" as the first arg)
For global install: "openocean-mcp"
args: An array of arguments to pass to the command.
For pnpm dlx: ["dlx", "openocean-mcp"]
For global install: []
env: An object containing environment variables to be set when the server process starts. This is where you provide any necessary environment variables.
workingDirectory: Generally not required when using the published package via pnpm dlx or a global install, as the package should handle its own paths correctly. If you were running from source (node dist/index.js), then setting workingDirectory to the project root would be important.
Get chain list
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get chain list' implies a read-only operation, but it fails to detail any behavioral traits such as rate limits, authentication needs, or what the output entails (e.g., format, data structure). This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the key action ('Get') and resource ('chain list'). There is no wasted language or redundancy, making it efficiently structured for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what a 'chain list' returns (e.g., a list of blockchain networks, their IDs, or configurations), leaving the agent without necessary context to understand the tool's output or its utility compared to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema coverage is 100%, so there are no parameters to document. The description does not need to add parameter semantics, and it appropriately avoids unnecessary details, aligning with the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get chain list' is a tautology that essentially restates the tool name 'CHAIN_LIST' without adding meaningful clarification. While it indicates a retrieval action ('Get'), it doesn't specify what a 'chain list' contains or how it differs from sibling tools like DEX_LIST or TOKEN_LIST, leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about its role relative to siblings such as DEX_LIST or TOKEN_LIST, and there are no explicit instructions on prerequisites or exclusions, making it unclear when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dex list
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | The blockchain network to execute the transaction on. uses fraxtal as default | fraxtal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get dex list' implies a read operation but doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is under-specification rather than effective conciseness. The description fails to provide essential information about what the tool does, making it inefficient despite its brevity. Every word should earn its place, but here the words don't provide enough value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description should provide more complete context about what this tool returns and how it behaves. 'Get dex list' doesn't explain what a dex list contains, whether it's filtered or comprehensive, or what the response format looks like. For a tool in a blockchain context with multiple sibling tools, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema documents one parameter with 100% coverage. Since schema_description_coverage is high, the baseline score is 3 even though the description adds no parameter information. The schema adequately describes the 'chain' parameter with its default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get dex list' is a tautology that essentially restates the tool name 'DEX_LIST'. It doesn't specify what a 'dex list' actually contains or what resource is being retrieved. While it includes a verb ('Get'), it lacks specificity about what kind of data is returned or the scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. With sibling tools like TOKEN_LIST, CHAIN_LIST, and SWAP available, there's no indication of how DEX_LIST differs from these other list-related tools or when it would be the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get gas price
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | The blockchain network to execute the transaction on. uses fraxtal as default | fraxtal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get gas price' implies a read-only operation, but it does not specify aspects like whether it requires authentication, rate limits, data freshness, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, which is efficient and front-loaded. However, this brevity borders on under-specification, as it lacks necessary details for clarity and completeness. It earns a high score for conciseness but loses a point for not providing enough substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It does not explain what the gas price represents (e.g., in wei or gwei), how it's sourced, or what the return value looks like. Without annotations or an output schema, the description should compensate more to ensure the agent can use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'chain' parameter fully documented in the schema itself. The description does not add any meaning beyond the schema, as it mentions no parameters. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get gas price' clearly states the action (get) and resource (gas price), making the purpose understandable. However, it lacks specificity about what exactly is retrieved (e.g., current price, historical data, or estimates) and does not distinguish this tool from potential siblings like GET_TRANSACTION that might involve gas-related data. This makes it vague but minimally viable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like QUOTE and SWAP that might involve gas calculations, there is no indication of whether this tool is for standalone gas price checks or part of a broader workflow. This absence of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Transaction
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | The blockchain network to execute the transaction on. uses fraxtal as default | fraxtal |
| hash | Yes | Hash from the OpenOcean contract on the blockchain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. It doesn't indicate whether this is a read-only operation, whether it requires authentication, what rate limits might apply, what happens if the transaction hash doesn't exist, or what format the response takes. The description adds zero behavioral context beyond the minimal implication of 'get' as a retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this represents under-specification rather than effective brevity. The description fails to provide necessary information that would help an AI agent understand and use the tool correctly. Every sentence should earn its place, but here the single 'sentence' (really just a phrase) doesn't earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of blockchain transactions and the absence of both annotations and output schema, the description is completely inadequate. It doesn't explain what information is returned, what format it's in, whether this is a read operation, or any error conditions. For a tool that presumably retrieves detailed blockchain transaction data, this minimal description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters well-documented in the schema itself. The description adds no parameter information beyond what's already in the structured schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Transaction' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what kind of transaction (crypto, blockchain, etc.) or what information is retrieved. While the input schema provides some clues, the description itself fails to communicate purpose beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus the sibling tools (CHAIN_LIST, DEX_LIST, GAS_PRICE, QUOTE, SWAP, TOKEN_LIST). It doesn't indicate this is for retrieving transaction details versus executing transactions (SWAP) or getting quotes (QUOTE). No context about prerequisites or alternatives is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quote the price of a specific trading pair
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | The blockchain network to execute the transaction on. uses fraxtal as default | fraxtal |
| inTokenAddress | Yes | The token to swap from (address). | |
| outTokenAddress | Yes | The token to swap to (address). | |
| amount | Yes | Token amount with decimals. For example, if 1 USDT is input, use 1000000 (1 USDT * 10^6). | |
| slippage | No | Define the acceptable slippage level by inputting a percentage value within the range of 0.05 to 50. 1% slippage set as 1. | 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool quotes prices but doesn't describe what the quote includes (e.g., exchange rate, fees, validity period), whether it's a read-only operation, potential rate limits, or error conditions. This leaves significant gaps for a tool that likely interacts with external APIs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial quoting tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the quote output includes (e.g., price, fees, timestamp), how it's calculated, or any behavioral aspects like caching or reliability. This leaves the agent with incomplete information for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide usage examples). With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Quote the price of a specific trading pair,' which specifies the verb ('quote') and resource ('price of a specific trading pair'). It distinguishes from siblings like SWAP (which executes trades) and TOKEN_LIST (which lists tokens), but doesn't explicitly differentiate from all siblings (e.g., GAS_PRICE also provides pricing information).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use QUOTE instead of SWAP (for execution) or other pricing-related tools like GAS_PRICE, nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Building swap transaction
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | The blockchain network to execute the transaction on. uses fraxtal as default | fraxtal |
| inTokenAddress | Yes | The token to swap from (address). | |
| outTokenAddress | Yes | The token to swap to (address). | |
| amount | Yes | Token amount with decimals. For example, if 1 USDT is input, use 1000000 (1 USDT * 10^6). | |
| slippage | No | Define the acceptable slippage level by inputting a percentage value within the range of 0.05 to 50. 1% slippage set as 1. | 1 |
| account | Yes | user's wallet address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'building swap transaction,' which implies a write operation (transaction creation), but doesn't clarify if this executes the transaction, requires user approval, involves costs, or has rate limits. This is a significant gap for a financial tool with potential real-world impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Building swap transaction')—a single phrase that front-loads the core purpose without unnecessary elaboration. Every word earns its place, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial swap tool with no annotations and no output schema, the description is inadequate. It doesn't cover behavioral aspects (e.g., execution, costs), output expectations, or integration with sibling tools. For a 6-parameter tool that likely involves blockchain transactions, more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters like inTokenAddress and outTokenAddress). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('building') and resource ('swap transaction'), making the purpose understandable. However, it doesn't differentiate from sibling tools like QUOTE (which might provide price quotes) or GET_TRANSACTION (which might retrieve transaction details), leaving room for ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like QUOTE or TOKEN_LIST. The description lacks context about prerequisites (e.g., needing token addresses from TOKEN_LIST) or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get token list
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | The blockchain network to execute the transaction on. uses fraxtal as default | fraxtal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get token list' implies a read operation, but it doesn't specify whether this is a safe query, requires authentication, has rate limits, or what the return format might be. For a tool with zero annotation coverage, this is inadequate, as it leaves key behavioral traits undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Get token list' is extremely concise with no wasted words, making it front-loaded and easy to parse. However, it's arguably too brief, bordering on under-specification, which slightly reduces its effectiveness. It earns a high score for efficiency but loses a point for potential lack of clarity due to brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple with 1 parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'token list' entails, how results are returned, or any behavioral aspects. For a tool in this context, the description should provide more detail to be fully helpful, making it inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, detailing 'chain' as the blockchain network with a default. The description adds no parameter semantics beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3, which applies here as the description doesn't compensate or add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get token list' states a verb ('Get') and resource ('token list'), providing a basic purpose. However, it's vague about what 'token list' means (e.g., tokens on a blockchain, tokens in a wallet, or something else) and doesn't distinguish from siblings like CHAIN_LIST or DEX_LIST. It meets the minimum viable standard but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, and with siblings like CHAIN_LIST and DEX_LIST that might overlap in domain, the absence of usage guidelines is a clear gap. This falls short of implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0CHAIN_LIST1 field changedInput schema / additionalPropertiesAdded value: +falseDEX_LIST2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseGAS_PRICE2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseGET_TRANSACTION2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseQUOTE2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseSWAP2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseTOKEN_LIST2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseCHAIN_LISTDEX_LISTGAS_PRICEGET_TRANSACTIONQUOTESWAPTOKEN_LISTScored across 7 tools
Each tool has a clearly distinct purpose targeting different aspects of DeFi operations: chain management, DEX listings, gas pricing, transaction retrieval, price quoting, swap building, and token listings. There is no overlap in functionality, making tool selection straightforward for an agent.
Most tools follow a consistent verb_noun pattern (e.g., GET_TRANSACTION, GAS_PRICE, TOKEN_LIST), but there are minor deviations: CHAIN_LIST and DEX_LIST use noun_verb order, and QUOTE and SWAP are single verbs without nouns. The naming is still readable and mostly predictable.
With 7 tools, the server is well-scoped for a DeFi/blockchain utility, covering essential operations like listing resources, pricing, transactions, and swaps. Each tool earns its place without feeling bloated or insufficient for the domain.
The toolset provides strong coverage for core DeFi workflows: resource listing (chains, DEXs, tokens), pricing (gas, quotes), and transaction handling (get, build swaps). A minor gap is the lack of tools for managing user accounts or executing swaps directly, but agents can work around this with the provided building blocks.
Doc search, intent & cross-chain swaps, limit orders, portfolio, spot prices, gas & all APIs.
Gate DEX MCP for wallet auth, transfers, swaps, token info, market data, and RPC access.
Cross-network DeFi API data, AMM analytics, and SDK docs for 17+ networks.
Token swaps and honeypot/rug checks for AI agents on 8 chains, paid per-call in USDC via x402.
