Integración de intercambio de criptomonedas de alto rendimiento utilizando MCP (Protocolo de contexto de modelo) y CCXT.
🚀 Soporte de intercambio : se conecta a más de 20 intercambios de criptomonedas
🔃 Tipos de mercado : Admite mercados al contado, futuros, swaps y más
🔧 Configuración de Proxy : Opciones para acceder a los exchanges a través de proxies
📊 Rápido y confiable : almacenamiento en caché optimizado y limitación de velocidad
🌐 Estándar MCP : Compatible con LLM como Claude y GPT a través de MCP
Related MCP server: binance-futures-mcp
El servidor CCXT MCP conecta los modelos de lenguaje con las plataformas de intercambio de criptomonedas mediante el Protocolo de Contexto de Modelo. Actúa como puente que permite a los LLM acceder a datos de mercado en tiempo real y ejecutar operaciones de trading en múltiples plataformas mediante una API unificada.
La arquitectura incluye:
Clientes LLM (Claude y otros modelos compatibles con MCP) que envían solicitudes
El Protocolo de Contexto Modelo (MCP) que estandariza la comunicación
El servidor MCP CCXT que procesa solicitudes y administra interacciones de intercambio
La biblioteca CCXT que proporciona acceso unificado a las API de intercambio
Conexiones a múltiples intercambios de criptomonedas
El servidor está organizado en tres módulos principales para una mejor mantenibilidad y extensibilidad:
Exchange : administra instancias de intercambio, credenciales y validación de símbolos.
Utilidades : proporciona funciones de almacenamiento en caché, limitación de velocidad y registro.
Herramientas : Implementa herramientas y recursos MCP para la interacción de intercambio
Para instalar mcp-server-ccxt para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @doggybee/mcp-server-ccxt --client claudePuede instalar CCXT MCP Server desde npm:
# Install globally
npm install -g @mcpfun/mcp-server-ccxt
# Start the server
mcp-server-ccxtO ejecutar directamente:
npx @mcpfun/mcp-server-ccxtAlternativamente, puedes clonar y construir el repositorio:
# Clone the repository
git clone https://github.com/doggybee/mcp-server-ccxt.git
cd mcp-server-ccxt
# Install dependencies
npm install
# Build the server
npm run build
# Start the server
npm startCrear un archivo de entorno
cp .env.example .envEdite el archivo .env para agregar sus claves API de intercambio
# Default exchange (optional)
DEFAULT_EXCHANGE=binance
# Default market type (optional)
DEFAULT_MARKET_TYPE=spot
# API credentials (optional)
BINANCE_API_KEY=your_api_key
BINANCE_SECRET=your_api_secret
# Proxy configuration (optional)
USE_PROXY=false
PROXY_URL=http://username:password@your-proxy-server:port
# Legacy format (still supported but recommended to use the integrated URL format above)
# PROXY_USERNAME=
# PROXY_PASSWORD=Nota : Si encuentra algún problema con la comunicación MCP, consulte la Guía de solución de problemas para obtener soluciones.
Iniciar el servidor:
# If installed globally via npm
mcp-server-ccxt
# If installed manually
npm startAgregue el servidor a su claude_desktop_config.json :
Si se instala a través de npm (globalmente):
{
"mcpServers": {
"ccxt": {
"command": "mcp-server-ccxt"
}
}
}Si se instala manualmente:
{
"mcpServers": {
"ccxt": {
"command": "node",
"args": [
"/path/to/mcp-server-ccxt/build/index.js"
]
}
}
}Reiniciar Claude para escritorio
También puedes usar este paquete como módulo en tus propios proyectos Node.js:
// Import the CCXT MCP Server
import '@mcpfun/mcp-server-ccxt';
// The server starts automatically when imported
// You can configure it through environment variablesA continuación se muestran algunos ejemplos de consultas que puede utilizar con el servidor MCP:
"¿Cuál es el precio actual de Bitcoin en Binance?"
"Muéstrame el libro de órdenes de ETH/USDT en Coinbase"
Consulta los datos OHLCV de 1 hora de BTC/USDT en Binance para las últimas 24 velas.
Comparar el precio de SOL/USDT en diferentes exchanges.
¿Cuál es mi saldo actual en Binance? (requiere claves API)
"Realice una orden de compra de mercado por 0,1 ETH en Kraken" (requiere claves API)
list-exchanges : lista todos los intercambios de criptomonedas disponibles
get-ticker : Obtenga información actualizada del ticker para un par comercial
batch-get-tickers : Obtenga información de tickers para múltiples pares comerciales a la vez
get-orderbook / get-order-book : Obtener el libro de órdenes de mercado para un par comercial
get-ohlcv : obtiene datos de velas OHLCV para un par comercial
get-trades : Obtenga operaciones recientes de un par comercial
get-markets : Obtenga todos los mercados disponibles para un intercambio
get-exchange-info : Obtener información y estado del intercambio
get-leverage-tiers : Obtener niveles de apalancamiento de futuros
get-funding-rates : Obtenga las tasas de financiación actuales
get-positions : Obtener información sobre puestos vacantes
get-open-orders : Obtener todos los pedidos abiertos
get-order-history : Obtener el historial de pedidos
account-balance : Obtenga el saldo de su cuenta de un intercambio de criptomonedas
place-market-order : Colocar una orden de mercado en una bolsa
place-limit-order : Colocar una orden limitada en una bolsa
cancel-order : Cancelar un pedido existente
cancel-all-orders : Cancelar todos los pedidos abiertos
set-leverage : Establecer apalancamiento para futuros
set-margin-mode : Establecer el modo de margen para futuros
place-futures-market-order : colocar órdenes en el mercado de futuros
place-futures-limit-order : colocar órdenes límite de futuros
transfer-funds : transferir fondos entre cuentas (por ejemplo, al contado a futuros)
cache-stats : Obtener estadísticas de caché CCXT
clear-cache : Limpiar la caché CCXT
set-log-level : Establecer el nivel de registro
get-proxy-config : Obtener la configuración del proxy
set-proxy-config : Configurar los ajustes del proxy
set-market-type : Establecer el tipo de mercado predeterminado
set-default-exchange : cambia el intercambio predeterminado
system-info : Obtener información del sistema y del entorno
MCP-CCXT incluye varias optimizaciones para garantizar un alto rendimiento:
Sistema de almacenamiento en caché LRU :
Diferentes TTL para diferentes tipos de datos
Datos del ticker: 10 segundos
Datos del libro de pedidos: 5 segundos
Datos de mercado: 1 hora
Limitación de velocidad adaptativa :
Ajusta automáticamente las tasas de solicitud en función de las respuestas del intercambio.
Implementa un retroceso exponencial para errores
Gestiona solicitudes simultáneas por intercambio
Gestión de conexiones de Exchange :
Inicialización eficiente de instancias de intercambio
Manejo adecuado de errores y reintentos
Crear claves API dedicadas :
Cree claves API independientes para diferentes aplicaciones y propósitos
Nunca reutilice claves API en diferentes servicios o aplicaciones
Limitar permisos de clave API :
Habilite solo los permisos que necesita (por ejemplo, solo lectura para datos de mercado)
Deshabilite los permisos de retiro si solo necesita la funcionalidad comercial
Utilice la lista blanca de IP cuando esté disponible para restringir el acceso a IP conocidas
Almacenamiento seguro :
Nunca envíe claves API a sistemas de control de versiones
Almacenar claves API en variables de entorno o en una bóveda segura
Utilice archivos .env que estén excluidos de git a través de .gitignore
Este software se proporciona únicamente con fines informativos. Su uso para interactuar con plataformas de intercambio de criptomonedas conlleva riesgos significativos:
Riesgo financiero : el comercio de criptomonedas implica riesgo de pérdida.
Seguridad de la API : asegúrese de que sus claves API tengan límites de permisos adecuados
Sin asesoramiento de inversión : esta herramienta no proporciona asesoramiento de inversión.
Sin garantía : el software se proporciona "tal cual", sin garantía de ningún tipo.
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo LICENSE.txt para obtener más detalles.
Este proyecto utiliza la biblioteca CCXT ( https://github.com/ccxt/ccxt ), que es:
Copyright (c) 2016-2024 CCXT developersCCXT se publica bajo la licencia MIT, que se incluye a continuación:
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.Para problemas, solicitudes de funciones o contribuciones, visite el repositorio de GitHub .
Get your account balance from a crypto exchange
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | API key for authentication | |
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| marketType | No | Market type (default: spot) | |
| passphrase | No | Passphrase for authentication (required for some exchanges like KuCoin) | |
| secret | Yes | API secret for authentication |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't disclose important behavioral aspects: authentication requirements (though hinted in parameters), rate limits, whether this is a real-time or cached balance, error conditions, or what format the balance information returns. For a financial tool with authentication parameters, this is a significant gap.
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 gets straight to the point with zero wasted words. It's appropriately sized for a straightforward data retrieval tool and front-loads the essential information without unnecessary elaboration.
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?
For a financial tool with authentication parameters and no output schema, the description is insufficiently complete. It doesn't explain what the balance information includes (total balance, available balance, by currency), doesn't mention error handling for invalid credentials, and provides no context about how this tool fits within the broader crypto exchange operations available in the sibling toolset.
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 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (like which exchanges require passphrase) or provide examples beyond the basic purpose statement. This meets the baseline for high schema coverage.
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 action ('Get') and resource ('account balance from a crypto exchange'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools that might also retrieve balance information or explain what distinguishes 'account balance' from other financial data tools in the server.
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 multiple sibling tools like 'get-exchange-info', 'get-funding-rates', and various order placement tools, there's no indication of when account balance retrieval is appropriate versus other financial data tools or how it relates to the broader toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ticker information for multiple trading pairs at once
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| marketType | No | Market type (default: spot) | |
| symbols | Yes | List of trading pair symbols (e.g., ['BTC/USDT', 'ETH/USDT']) |
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 action ('Get') but doesn't describe traits like whether this is a read-only operation (implied but not confirmed), rate limits, error handling for invalid symbols, or the format of returned ticker information. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 front-loads the core purpose without unnecessary words. It directly communicates the tool's function and scope ('multiple trading pairs at once'), making it easy to parse and understand quickly. Every part of the sentence earns its place.
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 (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'ticker information' includes (e.g., price, volume), how errors are handled, or the return format. For a data-fetching tool with multiple inputs, more context is needed to guide effective use, especially without annotations or output schema.
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 fully documents all three parameters (exchange, marketType, symbols) with descriptions and enums. The description adds no additional meaning beyond what's in the schema, such as examples of ticker data or constraints on symbol formats. 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 'Get' and resource 'ticker information for multiple trading pairs', which is specific and actionable. It distinguishes from the sibling 'get-ticker' by emphasizing 'multiple trading pairs at once', though it doesn't explicitly name the sibling. The purpose is well-defined but could be slightly more precise about what 'ticker information' entails.
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 like 'get-ticker' (for single pairs) or 'get-markets' (for broader market data). It lacks context about prerequisites, such as needing valid exchange and symbol inputs, or exclusions like unsupported market types. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CCXT cache statistics
| 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 full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify what statistics are returned, format, whether it requires authentication, or any performance/rate limit considerations. The description is too minimal for a tool that presumably returns system metrics.
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 with no wasted words. It's appropriately sized for a simple tool and front-loads the essential information immediately.
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?
For a statistics retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what statistics are returned, their format, or any behavioral aspects. The description should provide more context about what 'cache statistics' encompasses given the lack of structured output documentation.
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 zero parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to compensate for any parameter documentation gaps, though it also doesn't add any parameter-specific information beyond what the empty schema already indicates.
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 CCXT cache statistics' clearly states the verb ('Get') and resource ('CCXT cache statistics'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'clear-cache' or 'clear-exchange-cache', which would require explicit comparison to achieve a perfect score.
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. There's no mention of prerequisites, timing considerations, or how it differs from related cache operations like 'clear-cache' or 'clear-exchange-cache' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear CCXT cache
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Clear CCXT cache' implies a destructive operation but doesn't specify what gets cleared (e.g., all cache, specific data), whether it's reversible, permission requirements, or side effects. This is inadequate for a mutation tool with zero annotation coverage.
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 phrase with no wasted words. It's front-loaded and directly states the tool's function, making it highly concise and well-structured for quick comprehension.
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 no annotations, no output schema, and a destructive-sounding operation, the description is incomplete. It lacks details on behavior, outcomes, or error conditions, which are crucial for an agent to use this tool safely and effectively in context with sibling tools.
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?
With 0 parameters and 100% schema description coverage, the baseline is high. The description doesn't need to explain parameters, and it doesn't add or detract from the schema. A score of 4 reflects that the description is appropriate 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 'Clear CCXT cache' clearly states the action (clear) and target resource (CCXT cache), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'clear-exchange-cache', which appears to serve a similar function, preventing a perfect score.
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 like 'clear-exchange-cache' or when cache clearing is appropriate. It lacks context about prerequisites, timing, or comparison with sibling tools, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear exchange instance cache to apply configuration changes
| 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 full burden. It states the tool performs a destructive cache-clearing action but does not disclose behavioral traits like permissions required, side effects on system performance, whether it's reversible, or error conditions. The phrase 'to apply configuration changes' hints at a use case but lacks operational details.
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 front-loads the core action ('clear exchange instance cache') and adds value with the purpose clause ('to apply configuration changes'). There is no wasted verbiage or redundancy.
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 (destructive cache operation), lack of annotations, and no output schema, the description is minimally adequate. It states what the tool does and why, but fails to provide critical behavioral context like safety warnings, expected outcomes, or error handling, leaving gaps for an agent to operate safely.
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 with 100% schema description coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage context, which aligns with the baseline for zero-parameter tools.
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 action ('clear') and target ('exchange instance cache'), with the purpose 'to apply configuration changes' providing specific context. It distinguishes from the generic 'clear-cache' sibling tool by specifying 'exchange instance' scope, though not explicitly contrasting them.
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 implies usage when configuration changes need application, suggesting a post-configuration context. However, it lacks explicit guidance on when to use this versus 'clear-cache' or other cache-related tools, and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get exchange information and status
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| marketType | No | Market type (default: spot) |
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 retrieves information but doesn't clarify what 'information and status' entails, whether it's read-only, requires authentication, has rate limits, or returns structured data. 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 a single, efficient sentence with no wasted words, making it easy to parse. However, it could be more front-loaded with critical details like the tool's scope or differentiation from siblings, though it remains appropriately concise for its 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 complexity of financial exchange tools, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'information and status' includes, how results are formatted, or error handling, leaving gaps for an agent to operate effectively in this domain.
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%, with clear descriptions for both parameters, including an enum for 'marketType'. The description adds no additional parameter semantics beyond what the schema provides, such as examples of exchange IDs beyond 'binance' or 'coinbase', or details on default behavior. 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 states the tool's purpose as 'Get exchange information and status', which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'list-exchanges' or 'get-market-types', leaving ambiguity about what specific information is retrieved. The purpose is understandable but lacks specificity compared to alternatives.
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 such as 'list-exchanges' or 'get-market-types'. The description doesn't mention prerequisites, exclusions, or contextual cues for selection, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current funding rates for perpetual contracts
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, bybit) | |
| marketType | No | Market type (default: swap) | swap |
| symbols | No | List of trading pair symbols (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, latency expectations, rate limits, authentication requirements, or what format the funding rates are returned in. The description is functional but lacks operational 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 a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a straightforward data retrieval tool and front-loads the essential information.
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?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what funding rates are, how they're calculated, typical use cases, or what the return data looks like. The agent would need to guess about the output format and operational characteristics.
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 all parameters are documented in the schema itself. The description doesn't add any parameter-specific context beyond what's in the schema, such as explaining why 'exchange' is required or how 'symbols' filtering works. This meets the baseline for high schema coverage.
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 action ('Get') and target resource ('current funding rates for perpetual contracts'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-ticker' or 'get-ohlcv' that also retrieve market data but for different metrics.
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 doesn't mention prerequisites, context for funding rates in trading, or when other tools like 'get-ticker' might be more appropriate for different market data needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get futures leverage tiers for trading pairs
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, bybit) | |
| marketType | No | Market type (default: future) | future |
| symbol | No | Trading pair symbol (optional, e.g., BTC/USDT) |
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 a read operation ('Get'), implying it's likely non-destructive, but doesn't specify permissions, rate limits, response format, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves in practice.
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 with no wasted words. It's front-loaded with the core purpose and avoids unnecessary elaboration, making it easy to parse quickly while conveying the essential action.
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 for a tool that likely returns structured financial data. It doesn't explain what leverage tiers entail (e.g., margin requirements, tier levels) or the format of the response, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.
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 input schema fully documents all parameters (exchange, marketType, symbol). The description adds no additional semantic context beyond implying these parameters are used to fetch leverage tiers, which the schema already covers. This meets the baseline for high schema coverage.
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 action ('Get') and resource ('futures leverage tiers for trading pairs'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'set-leverage' or 'get-exchange-info', which would require more specific language about what distinguishes this retrieval 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 on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., for risk management or trading setup), or comparisons to siblings like 'get-exchange-info' or 'set-leverage', leaving the agent to infer usage scenarios without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available markets for an exchange
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| page | No | Page number | |
| pageSize | No | Items per page |
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 the action ('Get') but doesn't describe whether this is a read-only operation, if it requires authentication, rate limits, or what the return format looks like. This leaves significant gaps for an agent to understand how to handle the tool effectively.
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 any unnecessary words. It's front-loaded and appropriately sized for its function, making it easy to parse quickly.
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 tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, or behavioral traits like pagination details, leaving the agent with incomplete information to use the tool correctly.
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, so the schema already documents all parameters (exchange, page, pageSize) adequately. The description doesn't add any extra meaning beyond implying that 'exchange' is required, which is already in the schema, resulting in a baseline score of 3.
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 ('Get') and resource ('all available markets for an exchange'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-exchange-info' or 'get-market-types', which might have overlapping functionality, so it doesn't reach the highest score.
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 like 'list-exchanges' or 'get-exchange-info'. It lacks context about prerequisites, such as needing an exchange ID, and doesn't mention any exclusions or specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get market types supported by an exchange
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, coinbase) |
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 describes a read operation ('Get'), which implies non-destructive behavior, but lacks details on permissions, rate limits, error handling, or return format. This is a significant gap for a tool with no annotation coverage.
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 any unnecessary words or fluff. It is 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 tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks usage guidelines, behavioral details, and output information, leaving gaps that could hinder effective tool selection and 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 input schema has 100% description coverage, with the 'exchange' parameter clearly documented. The description adds no additional meaning beyond the schema, such as examples of market types or context on what 'supported' entails. Baseline score of 3 is appropriate as the schema handles 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 'Get' and the resource 'market types supported by an exchange', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-markets' or 'get-exchange-info', which might overlap in functionality, preventing a perfect score.
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 such as 'get-markets' or 'get-exchange-info', nor does it mention any prerequisites or exclusions. It only states what the tool does, leaving usage context implied and incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OHLCV candlestick data for a trading pair
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| limit | No | Number of candles to fetch (max 1000) | |
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT) | |
| timeframe | No | Timeframe (e.g., 1m, 5m, 1h, 1d) | 1d |
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 only states the basic action without details on rate limits, authentication needs, data freshness, or error handling. It fails to address key operational traits beyond the minimal purpose.
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 is front-loaded and appropriately sized, with no wasted 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 complexity of financial data retrieval, no annotations, and no output schema, the description is incomplete. It lacks details on return format, data structure, error cases, or operational constraints, making it insufficient for full contextual understanding.
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 input schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as examples or constraints not covered. This meets the baseline for high schema coverage.
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 ('Get') and resource ('OHLCV candlestick data for a trading pair'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get-ticker' or 'get-trades', which also retrieve market data but for different metrics, so it misses full sibling distinction.
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, such as 'get-ticker' for current prices or 'get-trades' for transaction data. It lacks context on prerequisites, exclusions, or comparisons to sibling tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get market order book for a trading pair
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| limit | No | Depth of the orderbook | |
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT) |
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 what the tool does but lacks critical details: whether this is a read-only operation, if it requires authentication, rate limits, latency, or what the output format looks like (e.g., bids/asks structure). For a financial data tool with no annotation coverage, this is a significant gap.
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 front-loads the core purpose without any wasted words. It directly communicates the tool's function in a compact form, making it easy to parse.
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 financial data retrieval, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like safety, performance, or output structure, which are crucial for an agent to use this tool effectively in a trading context.
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%, with clear descriptions for all three parameters (exchange, limit, symbol). The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'limit' affects order book depth or format examples. 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 action ('Get') and resource ('market order book for a trading pair'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'get-ticker' or 'get-trades' that also retrieve market data, missing explicit differentiation.
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 'get-ticker' (for price) and 'get-trades' (for recent trades), there's no indication of when order book data is preferred, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current proxy configuration
| 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 full burden but only states the action without behavioral details. It doesn't disclose if this is a read-only operation, requires authentication, has rate limits, returns structured data, or what happens on errors—critical gaps for a tool in a financial/API 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?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse for an AI agent.
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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the proxy configuration includes (e.g., settings, status), the return format, or error handling—leaving the agent unprepared for effective use in a complex sibling toolset.
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 with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline high score for not adding unnecessary information.
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 ('Get') and resource ('proxy configuration'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'test-proxy-connection' or 'set-proxy-config', which would require more specificity about what 'current' means in this context.
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 like 'test-proxy-connection' or 'set-proxy-config'. There's no mention of prerequisites, timing, or comparative use cases, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current ticker information for a trading pair
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| marketType | No | Market type (default: spot) | |
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT) |
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 it 'gets' information, implying a read-only operation, but doesn't mention potential side effects like caching, rate limits, authentication needs, or response format. This is inadequate for a tool with no annotation coverage.
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 is appropriately sized and front-loaded, making it easy to parse quickly.
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 doesn't explain what 'ticker information' includes (e.g., price, volume), potential errors, or behavioral traits like real-time vs. cached data. For a financial data tool with no structured output, more context is needed.
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 clear descriptions for all parameters (exchange, marketType, symbol). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score for high schema coverage.
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 ('Get') and resource ('current ticker information for a trading pair'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'batch-get-tickers' or 'get-exchange-info', which prevents a perfect score.
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 like 'batch-get-tickers' for multiple pairs or 'get-exchange-info' for exchange metadata. It lacks context on prerequisites or exclusions, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent trades for a trading pair
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| limit | No | Number of trades to fetch | |
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Get recent trades' but doesn't specify what 'recent' means (time window), whether there are rate limits, authentication requirements, or what format the trades come in. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
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 at just 6 words, front-loading the essential information with zero wasted words. Every element ('Get', 'recent trades', 'for a trading pair') serves a clear purpose in communicating the tool's function.
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?
For a data retrieval tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'recent' means, what data format to expect, whether there are limitations or constraints, or how this differs from similar market data tools. The context signals indicate this tool needs more complete documentation.
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 doesn't add any parameter information beyond what's already in the schema (which has 100% coverage). It mentions 'trading pair' which aligns with the 'symbol' parameter, but provides no additional context about parameter interactions, constraints, or usage patterns. With complete 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 action ('Get recent trades') and resource ('for a trading pair'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get-ohlcv' or 'get-orderbook' that also retrieve market data, which prevents a perfect score.
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 like 'get-ohlcv' for historical data or 'get-orderbook' for depth information. There's no mention of prerequisites, timing considerations, or specific use cases for trade data versus other market data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available cryptocurrency exchanges
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'List all available cryptocurrency exchanges' implies a read-only operation, it doesn't specify whether this requires authentication, what format the results come in, whether there are rate limits, or if the data is cached. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 states exactly what the tool does with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the core functionality. Every word earns its place in conveying the tool's purpose.
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?
For a simple listing tool with 0 parameters and no output schema, the description provides the basic purpose but lacks important context. Without annotations or output schema, the agent doesn't know what format the exchange list comes in, whether authentication is required, or how to interpret the results. The description is minimally adequate but leaves significant gaps in understanding how to effectively use this tool.
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist. This earns a baseline 4 for parameter semantics as there's nothing to compensate for and no misleading parameter information.
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 ('List') and resource ('all available cryptocurrency exchanges'), making the purpose immediately understandable. It distinguishes from siblings like 'get-exchange-info' by focusing on listing rather than retrieving detailed information about a specific exchange. However, it doesn't explicitly differentiate from other listing tools like 'get-markets'.
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 'get-exchange-info' (for detailed exchange information) and 'get-markets' (for listing markets rather than exchanges), the agent receives no help in choosing between these related tools. There are no explicit when/when-not statements or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a futures market order
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to buy/sell | |
| apiKey | Yes | API key for authentication | |
| exchange | Yes | Exchange ID (e.g., binance, bybit) | |
| marketType | No | Market type (default: future) | future |
| params | No | Additional order parameters | |
| passphrase | No | Passphrase for authentication (required for some exchanges like KuCoin) | |
| secret | Yes | API secret for authentication | |
| side | Yes | Order side: buy or sell | |
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states it 'places' an order (implying a write/mutation operation) but doesn't mention authentication requirements (though parameters suggest them), rate limits, order execution behavior, error conditions, or what happens on success/failure. For a financial trading tool with significant implications, this is inadequate.
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 maximally concise at just 4 words - 'Place a futures market order.' It's front-loaded with the essential action and resource, with zero wasted words or unnecessary elaboration. This is an example of efficient communication when the schema provides detailed parameter documentation.
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?
For a complex financial trading tool with 9 parameters (including authentication credentials), no annotations, and no output schema, the description is severely incomplete. It doesn't explain what constitutes success/failure, return values, error handling, authentication requirements, or how this differs from sibling tools. The schema handles parameters well, but the overall context for safe and correct usage is missing.
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?
With 100% schema description coverage, the schema already documents all 9 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation entirely through the schema, though the description contributes nothing extra.
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 action ('place') and resource ('futures market order'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'place-market-order' - the only distinction appears to be 'futures' vs unspecified market type, but this isn't explicitly explained.
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 sibling tools like 'place-market-order' and 'set-market-type' available, there's no indication of when this futures-specific tool is appropriate versus using the more generic market order tool with market type configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a market order on an exchange
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to buy/sell | |
| apiKey | Yes | API key for authentication | |
| exchange | Yes | Exchange ID (e.g., binance, coinbase) | |
| marketType | No | Market type (default: spot) | |
| passphrase | No | Passphrase for authentication (required for some exchanges like KuCoin) | |
| secret | Yes | API secret for authentication | |
| side | Yes | Order side: buy or sell | |
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Place a market order' implies a financial transaction with potential risks, the description doesn't mention critical behavioral aspects like execution guarantees, slippage risks, authentication requirements beyond what's in the schema, rate limits, or what happens on failure. This is inadequate for a tool that executes financial trades.
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 - a single sentence that states the core purpose without any fluff or unnecessary elaboration. It's front-loaded with the essential information and wastes no words.
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?
For a tool that executes financial trades with 8 parameters and no annotations or output schema, the description is severely lacking. It doesn't explain what a market order is, how it differs from other order types, what the expected response format might be, or any error conditions. The context signals show this is a complex operation, but the description provides minimal context.
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 all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
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 action ('Place a market order') and resource ('on an exchange'), which is specific and unambiguous. However, it doesn't differentiate this tool from its sibling 'place-futures-market-order', which appears to be a specialized version for futures markets.
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 like 'place-futures-market-order' or other order types. There's no mention of prerequisites, constraints, or typical use cases for market orders versus limit orders or other trading operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set leverage for futures trading
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | API key for authentication | |
| exchange | Yes | Exchange ID (e.g., binance, bybit) | |
| leverage | Yes | Leverage value | |
| marketType | No | Market type (default: future) | future |
| passphrase | No | Passphrase for authentication (required for some exchanges like KuCoin) | |
| secret | Yes | API secret for authentication | |
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Set leverage' implies a write/mutation operation, but the description doesn't disclose critical behavioral traits: whether this requires specific permissions, what happens to existing positions when leverage changes, rate limits, error conditions, or what the response looks like. For a financial trading tool with zero annotation coverage, this is a significant gap.
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 maximally concise with a single, clear sentence that states the tool's purpose without any wasted words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point.
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?
For a financial trading tool that modifies leverage (a potentially risky operation), the description is incomplete. With no annotations, no output schema, and a description that only states the basic purpose, critical context is missing: what permissions are needed, what happens to existing positions, error handling, rate limits, and response format. The schema handles parameters well, but behavioral and operational context 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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. The baseline score of 3 reflects adequate parameter documentation entirely through the schema.
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 action ('Set leverage') and resource ('for futures trading'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'set-margin-mode' or 'set-market-type' that also configure trading parameters, leaving some 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, timing considerations, or comparison to sibling tools like 'set-margin-mode' or 'place-futures-market-order' that might be related. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set logging level
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | Logging level to set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Set logging level' implies a mutation operation, but it doesn't disclose behavioral traits such as whether changes are persistent, require restart, affect performance, have side effects, or what permissions are needed. This is a significant gap for a tool that likely modifies system state.
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 at three words, front-loaded with the core action. There's no wasted text or redundancy, making it easy to parse quickly. Every word earns its place by directly stating the tool's function.
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 logging configuration tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, side effects, return values, or error handling. For a mutation tool that could affect system diagnostics, 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?
The input schema has 100% description coverage, with the 'level' parameter documented as 'Logging level to set' and an enum of values. The description doesn't add meaning beyond this, such as explaining the impact of each level or default behavior. With high schema coverage, the baseline is 3, as 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 'Set logging level' states the verb ('Set') and resource ('logging level'), providing a basic purpose. However, it's vague about what exactly is being configured (e.g., system-wide, per-module, or for a specific component) and doesn't distinguish from siblings like 'set-proxy-config' or 'set-leverage' beyond the resource name. It avoids tautology 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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin access), context (e.g., debugging vs. production), or exclusions. With siblings like 'clear-cache' or 'test-proxy-connection', there's no indication of how this tool fits into broader workflows, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set margin mode for futures trading
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | API key for authentication | |
| exchange | Yes | Exchange ID (e.g., binance, bybit) | |
| marginMode | Yes | Margin mode: cross or isolated | |
| marketType | No | Market type (default: future) | future |
| passphrase | No | Passphrase for authentication (required for some exchanges like KuCoin) | |
| secret | Yes | API secret for authentication | |
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Set' implies a mutation operation, but the description doesn't disclose whether this requires specific permissions, whether changes are reversible, what happens to existing positions when margin mode changes, or any rate limits. For a financial trading tool with zero annotation coverage, this is a significant gap.
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 gets straight to the point with zero wasted words. It's appropriately sized for a tool with well-documented parameters in the schema.
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?
For a financial trading mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, what side effects occur, error conditions, or how this operation fits into broader trading workflows. The combination of mutation behavior, financial context, and lack of structured metadata requires more comprehensive description.
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 all parameters are documented in the schema itself. The description doesn't add any parameter semantics beyond what's already in the schema - it doesn't explain relationships between parameters (e.g., how 'exchange' affects which authentication parameters are needed) or provide usage examples. Baseline 3 is appropriate when 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 action ('Set') and resource ('margin mode for futures trading'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'set-leverage' or 'set-market-type' that also configure trading parameters, so it doesn't achieve full sibling differentiation.
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. There's no mention of prerequisites (like needing authentication), when margin mode changes are appropriate, or how this relates to sibling tools like 'set-leverage' or 'set-market-type' that also configure trading settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set default market type for all exchanges
| Name | Required | Description | Default |
|---|---|---|---|
| clearCache | No | Clear exchange cache to apply changes immediately | |
| marketType | Yes | Market type to set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose critical behavioral traits like whether this is a global configuration change, permission requirements, rate limits, or what happens to existing market data. The 'clearCache' parameter hints at some behavior but isn't explained in the description.
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 with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 this is a configuration mutation tool with no annotations and no output schema, the description is incomplete. It should explain the scope of changes (e.g., affects all exchanges globally), potential side effects, or what confirmation/error responses look like, but provides none of this context.
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 fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced coverage.
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 action ('Set') and the target ('default market type for all exchanges'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-market-types' or 'set-leverage', which would be needed for a perfect score.
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 prerequisites, side effects, or compare it to related tools like 'set-leverage' or 'set-margin-mode', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure proxy settings for all exchanges
| Name | Required | Description | Default |
|---|---|---|---|
| clearCache | No | Clear exchange cache to apply changes immediately | |
| enabled | Yes | Enable or disable proxy | |
| password | No | Proxy password (optional) | |
| url | Yes | Proxy URL (e.g., http://proxy-server:port) | |
| username | No | Proxy username (optional) |
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 'Configure proxy settings for all exchanges', implying a system-wide mutation, but fails to mention critical aspects like whether this requires elevated permissions, if changes are reversible, potential side effects on ongoing exchanges, or rate limits. This leaves significant gaps for a tool that modifies global settings.
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 for an agent to parse quickly.
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 configuring system-wide proxy settings, the description is insufficient. With no annotations, no output schema, and a mutation tool that could impact all exchanges, it should address permissions, side effects, or confirmation of changes. The current description leaves too many behavioral questions unanswered for 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?
The schema description coverage is 100%, providing clear documentation for all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters (e.g., username/password only needed when enabled) or format examples beyond the URL example already in the schema. This meets the baseline for high schema coverage.
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 action ('Configure') and resource ('proxy settings for all exchanges'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-proxy-config' or 'test-proxy-connection', which would require mentioning this is for setting/updating rather than retrieving or testing.
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 like 'get-proxy-config' or 'test-proxy-connection'. It lacks context about prerequisites, such as needing admin permissions or when proxy changes are appropriate, leaving the agent with no usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test the proxy connection with a specified exchange
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | Exchange ID to test connection with (e.g., binance) |
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 tests a proxy connection but doesn't explain what 'test' entails (e.g., whether it performs a network check, returns latency, or validates credentials), what happens on failure, or if it has side effects like logging. This is a significant gap for a tool with potential operational implications.
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, with every part contributing to understanding the tool's function.
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 doesn't explain what the test involves, what results to expect (e.g., success/failure status, latency metrics), or potential errors. For a tool that likely interacts with network configurations, more context is needed to guide 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%, with the parameter 'exchange' clearly documented in the input schema. The description adds no additional meaning beyond the schema (e.g., it doesn't clarify the format of 'exchange' beyond the example in the schema or explain why testing is needed). 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 action ('Test') and the resource ('proxy connection with a specified exchange'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'get-proxy-config' or 'set-proxy-config' among the sibling tools, which would require explicit differentiation for a score of 5.
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 prerequisites (e.g., after configuring a proxy), exclusions, or comparisons to sibling tools like 'get-proxy-config' or 'set-proxy-config', leaving the agent without context for selection.
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.0account-balancebatch-get-tickerscache-statsclear-cacheclear-exchange-cacheget-exchange-infoget-funding-ratesget-leverage-tiersget-market-typesget-marketsget-ohlcvget-orderbookget-proxy-configget-tickerget-tradeslist-exchangesplace-futures-market-orderplace-market-orderset-leverageset-log-levelset-margin-modeset-market-typeset-proxy-configtest-proxy-connectionScored across 24 tools
Most tools have distinct purposes, but there is some overlap between 'place-market-order' and 'place-futures-market-order', which could cause confusion if the agent doesn't understand the futures context. Additionally, 'clear-cache' and 'clear-exchange-cache' are similar, though the latter is more specific. Overall, descriptions help differentiate, but minor ambiguities exist.
Tool names follow a consistent verb_noun pattern with hyphens, such as 'get-ticker' and 'set-leverage', making them predictable and readable. However, there are minor deviations like 'batch-get-tickers' (which mixes verb order) and 'cache-stats' (which uses a noun-verb style), slightly breaking the pattern.
With 24 tools, the count is on the higher side but reasonable for a comprehensive crypto exchange server covering data retrieval, trading, configuration, and cache management. It might feel slightly heavy, but each tool appears to serve a specific function in the domain without obvious redundancy.
The tool set provides complete coverage for interacting with crypto exchanges, including market data (e.g., 'get-ohlcv', 'get-orderbook'), trading operations (e.g., 'place-market-order', 'set-leverage'), configuration (e.g., 'set-proxy-config'), and utility functions (e.g., 'cache-stats'). No significant gaps are apparent for the stated purpose.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
Real-time crypto market data: candles, tickers, orderbooks across 13+ exchanges via MCP.
Alpaca MCP — real-time US stock market data via the Alpaca Market Data API
