Loading ToolBench
MCP server for Skate AMM (Automated Market Maker) supporting both EVM and Solana/SVM chains via GOAT SDK integration
This MCP server exhibits significant quality gaps across naming, descriptions, and schema definitions. While the server implements 7 tools covering trading pair retrieval and swap operations on EVM/SVM chains, the tool definitions lack rigor expected for production use. Tool names are inconsistent (mixing verb_noun with namespace prefixes), descriptions are present but generic and lack dependency hints, and parameter schemas show incomplete type information and missing descriptions on several fields. Error handling guidance is absent, and no output schemas are documented. The server relies on STDIO transport, which is not remotely accessible and limits deployment options.
Retrieves all markets supported by the Skate AMM. Chain ID 901 is Solana, Chain ID 902 is Eclipse. The rest are EVM chains.
Returns the balance of an ERC20 token for a specific address, in decimal formatted, raw, and includes the raw decimals. Only on EVM chains.
Returns the balance of an SPL token for a specific address, in decimal formatted, raw, and includes the raw decimals. Only on EVM chains.
Returns the approval amounts of the owner & spender for a specified token. Must be checked before making a swap, Only on EVM chains.
Gets a Skate AMM quote for a desired asset pair on a specific sourceChain. Executes a swap on EVM chain. Check for sufficient token approval before executing a swap.
Gets a Skate AMM quote for a desired asset pair on a specific sourceChain. Executes a swap on SVM chain.
Inconsistent naming conventions: getTradingPairs uses camelCase while most others use snake_case with namespace prefix (skate_amm_*). This inconsistency confuses LLMs about tool discovery and selection.
Critical: No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does getTradingPairs return? Is there a pair_id field that swap tools need?). This violates pattern:tool requirement for documented return types.
swap tools lack error guidance. Descriptions state 'Check for sufficient token approval before executing a swap' but provide no actionable error responses if approval is insufficient. Pattern requires recovery guides: 'Approval insufficient. Call skate_amm_set_approval() first.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Sets the approval amounts of the owner & spender for a specified token already checked and approval is insufficient for amount to swap. Only on EVM chains.
Parameter descriptions lack detail on format, range, and constraints. For example, 'amountIn' is described as 'Amount of tokens to swap as string, pre parseUnits format' but does not specify valid range, minimum, or maximum. Numeric parameters (tokenDecimalIn, slippageLimit) lack min/max bounds.
Enum parameters not properly constrained. 'srcChainId' is declared type='enum' but no enum values are listed in the schema. 'chain' parameter in check_approval and balance tools similarly lacks enum values. LLMs cannot select valid options without explicit value lists.
No distinction between EVM and SVM tools in naming creates composition risk. When an agent has both execute_evm_swap and execute_svm_swap, the names do not clearly indicate which to call for a given chain. Description mentions chain IDs (901=Solana, 902=Eclipse) but parameter descriptions do not map chain inputs to correct tool.
Tool descriptions missing dependency hints. No tool explains when to call getTradingPairs vs directly calling swap tools, or whether chain discovery must precede swap execution. Pattern requires explicit sequencing guidance.
Descriptions for balance tools state 'Only on EVM chains' and 'Only on SVM chains' respectively, but this constraint should be enforced at the parameter level (e.g., enum values or validation error). Putting constraints only in descriptions forces LLMs to remember and enforce rules manually.