OpenOcean MCP

Official

by openocean-finance

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 2.4/5 across 7 of 7 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/5
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.
Behavior2/5
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.
Conciseness2/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose2/5
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.
Usage Guidelines1/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/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 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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
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 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.
Purpose4/5
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.
Usage Guidelines2/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openocean-mcp MCP server](https://glama.ai/mcp/servers/openocean-finance/openocean-mcp/badges/card.svg)](https://glama.ai/mcp/servers/openocean-finance/openocean-mcp)

Score Badge

Copy to your README.md:

[![openocean-mcp MCP server](https://glama.ai/mcp/servers/openocean-finance/openocean-mcp/badges/score.svg)](https://glama.ai/mcp/servers/openocean-finance/openocean-mcp)

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/openocean-finance/openocean-mcp'

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