MCP server for Hummingbot API integration - manage crypto trading across multiple exchanges
Three tools with complete schemas and detailed descriptions. setup_connector and get_portfolio_overview have excellent, LLM-optimized descriptions (200+ chars) with clear progressive disclosure patterns and parameter dependencies documented. configure_server is simpler but adequate. All tools have proper JSON Schema with types and descriptions for parameters. However, no tool annotations (readOnlyHint/destructiveHint) are present, and error handling guidance is minimal, descriptions explain what happens but not how to recover from failures. Output schemas are not formally documented in the code.
Configure the active Hummingbot API server connection. This tool manages a single API server connection: 1. No parameters → Show the current server configuration 2. Any parameters → Update the server config and reconnect Only the provided parameters are changed; omitted ones keep their current values.
Get a unified portfolio overview with balances, perpetual positions, LP positions, and active orders. This tool provides a comprehensive view of your entire portfolio by fetching data from multiple sources in parallel. By default, it returns all four types of data, but you can filter to only include specific sections. Data Sources (fetched in parallel using asyncio.gather): 1. Token Balances - Holdings across all connected CEX/DEX exchanges 2. Perpetual Positions - Open perpetual futures positions from CEX 3. LP Positions (CLMM) - Real-time concentrated liquidity positions from blockchain DEXs - Queries database to find all pools user has interacted with - Calls get_positions() for each pool to fetch real-time blockchain data - Includes real-time fees and token amounts 4. Active Orders - Currently open orders across all exchanges NOTE: This only shows ACTIVE/OPEN positions. For historical data, use search_history() instead.
Setup or delete an exchange connector for an account with credentials using progressive disclosure. This tool guides you through the entire process of connecting an exchange with a four-step flow: 1. No parameters → List available exchanges 2. Connector only → Show required credential fields 3. Connector + credentials, no account → Select account from available accounts 4. All parameters → Connect the exchange (with override confirmation if needed) Delete flow (action="delete"): 1. action="delete" only → List all accounts and their configured connectors 2. action="delete" + connector → Show which accounts have this connector configured 3. action="delete" + connector + account → Delete the credential
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. setup_connector and configure_server are destructive (WRITE risk) but lack destructiveHint annotation to signal this to clients.
Error handling descriptions lack recovery guidance. setup_connector mentions 'progressive disclosure' but does not explain what error states are possible or how the LLM should respond (e.g., 'If connector not found, call with no parameters to list available connectors').
Output schemas not formally documented. Tool descriptions explain what data is returned (e.g., 'portfolio overview with balances, positions, orders') but do not specify the exact JSON structure, field names, or types the LLM should expect.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
configure_server parameter descriptions lack format/constraint details. 'host' accepts 'localhost', 'host.docker.internal', or IP but does not specify valid formats (IPv4, IPv6, hostname pattern). 'port' is integer but no range (1 - 65535) is stated.
setup_connector 'credentials' parameter is a free-form dict with no schema. Description says 'Leave empty to see required fields first' but does not specify what fields are required for each connector or their types, forcing the LLM to call the tool twice to discover the schema.