MCP server providing tools for interacting with OKX blockchain and DeFi APIs for balance queries, gas operations, price data, trading, and transaction management
This MCP server exposes 11 blockchain query and transaction tools with moderate definition quality. Tool naming follows verb_noun convention (BALANCE_GET_*, GATEWAY_GET_*, etc.) which is positive. However, descriptions are generic and lack LLM-optimized guidance. Parameter schemas are present and use Zod validation, but descriptions are often too brief (under 50 chars) and lack actionable constraints. No output schemas are documented in visible code. Error handling is not evident in tool definitions. The codebase shows TypeScript/Zod infrastructure but lacks the polish expected of production agent tools.
Descriptions are generic and under 50 characters for most tools. Examples: 'Retrieve the list of token balances...' does not explain WHEN to use this tool vs similar balance tools, or what the LLM should expect in response.
No output schemas are documented. Tools return responses (e.g. GetSpecificTokenBalanceResponse, GetTotalValueResponse) but these types are not visible in the provided code, and there is no inline schema documentation in tool definitions.
Expand all tool descriptions to 100-200 characters (up from current 30-60). Include: what the tool does, when to use it (vs similar tools), and what it returns. Example: 'Get all token balances for a wallet across specified chains. Use this to see total holdings; call BALANCE_GET_TOTAL_VALUE instead for aggregate USD value. Returns array of {token, balance, chain, symbol}.'
Document output schemas inline or in a separate schema file. For each tool, specify response fields with types. Example for BALANCE_GET_TOTAL_VALUE: {address, totalUsdValue, chains: [{chainId, totalValue}], timestamp}.
Add enum constraints to 'chainIndex', 'chains', and 'assetType' parameters. Instead of 'Index of the blockchain chain', state: 'Chain identifier enum: ethereum, solana, polygon, arbitrum, optimism, etc. Call BALANCE_GET_SUPPORTED_CHAIN to list available chains.'
Add explicit error handling guidance to tool descriptions. Example: 'If chainIndex is not recognized, call BALANCE_GET_SUPPORTED_CHAIN to validate. Returns 400 Bad Request with message listing valid chains.'
Mark GATEWAY_BROADCAST_TRANSACTIONS as destructive in description: 'WARNING: This tool broadcasts signed transactions to the blockchain and is IRREVERSIBLE. Ensure transaction has been simulated (via GATEWAY_SIMULATE_TRANSACTIONS) and confirmed by the user before calling.' Optionally add a confirmation_required flag to the tool schema.
Standardize the 'chains' parameter format: use consistent array-of-strings or consistent string format across all tools. Update descriptions to clarify: 'Comma-separated chain identifiers (e.g., ethereum,solana,polygon)' or 'Array of chain identifiers.'
Score history
Overall score trend
First recorded score · v2 rubric
41/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
F
41
2026-07-28+
v2
read onlyauthsource verified47/100
Dynamically obtain estimated gas prices for various chains.
Parameter descriptions lack actionable constraints. For example, 'chainIndex' is described as 'Index of the blockchain chain', does this accept 'ethereum', 'solana', numeric IDs, or a specific enum? The description should state format, range, and valid values.
GATEWAY_BROADCAST_TRANSACTIONS is a destructive, write-capable tool but the description does not state this or explain prerequisites, idempotency, or recovery mechanisms. Agents need to know which calls are safe to retry and which have irreversible consequences.' Critical for agent safety.
No error handling or recovery guidance visible in tool definitions. A raw error code or stack trace gives the agent nothing to act on.' Tools should document expected error cases and recovery paths (e.g., 'If chainIndex is invalid, call BALANCE_GET_SUPPORTED_CHAIN first').
Parameter 'chains' in BALANCE_GET_TOTAL_TOKEN_BALANCES is typed as 'array of strings' but in BALANCE_GET_TOTAL_VALUE it is a single 'string' (comma-separated). This inconsistency forces the LLM to reason about which format to use.
Optional parameters like 'excludeRiskToken' lack clear documentation on default behavior. The description should state: 'Defaults to false (risk tokens included).'
Document default values explicitly. For 'excludeRiskToken', add: '(Optional, defaults to false. Set to true to exclude low-liquidity or high-risk tokens from results.)'
Add a discovery tool or enhance BALANCE_GET_SUPPORTED_CHAIN and GATEWAY_GET_SUPPORTED_CHAINS to return schemas of what each tool accepts. This reduces LLM guessing about valid parameter values.
Consider wrapping multi-step workflows (e.g., simulate → broadcast → poll status) into composite tools or add dependency hints in descriptions: 'Before calling GATEWAY_BROADCAST_TRANSACTIONS, always call GATEWAY_SIMULATE_TRANSACTIONS first to validate.'
Add per-item success/failure in batch-like results. If a tool accepts multiple token addresses, the response should indicate which succeeded and which failed, with reasons.