Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@3commas-mcp List all my DCA bots and their current status"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that integrates AI assistants with the 3Commas cryptocurrency trading platform API. Manage your DCA bots and trading strategies through natural conversation with any MCP-supporting platform including Claude, Claude Code CLI, Claude Desktop, Cursor, and Copilot Studio.
health_check() - Test API connectivity and authentication status
get_account_info(account_id) - Get account details, balance, profit metrics (summary or specific account)
get_connected_exchanges_and_wallets() - View all connected exchanges with permissions and status
get_balance_history_data(date_from, account_id) - Historical balance changes with profit tracking
get_supported_markets() - List supported trading markets and exchanges
get_all_market_pairs(market_code) - Get available trading pairs for any exchange
get_currency_rates_and_limits(market_code, pair) - Current rates, limits, and precision for currency pairs
get_dca_bot_list() - Get all DCA bots with status, configuration, and performance overview
get_dca_bot_details(bot_id) - Comprehensive bot configuration, deals, and performance data
get_available_strategy_list() - Available DCA bot trading strategies with configuration options
get_dca_bot_profit_data(bot_id) - Daily profit analytics with BTC/USD amounts and timestamps
get_blacklist_of_pairs() - Get blacklisted trading pairs with restrictions and configurations
Implementation Status: 10 of 29 planned GET APIs completed (34.5%) - Read-only operations only for trading safety
All tools include response_filter parameter ("display" for essential data, "full" for complete response).
See docs/tools/ for detailed function documentation and docs/API_REFERENCES.md for complete API status.
Related MCP server: ctrader-mcp-server
Python 3.12+
uv package manager (recommended) or pip
3Commas account with API access
git clone https://github.com/your-username/3commas-mcp.git
cd 3commas-mcp
# Setup environment
uv venv && source .venv/bin/activate
uv sync && uv pip install -e .claude mcp add -e 3COMMAS_API_KEY=your_api_key -e 3COMMAS_SECRET_KEY=your_secret_key -e 3COMMAS_ENABLE_DESTRUCTIVE=false -s user threecommas-mcp -- "threecommas-mcp"Add to claude_desktop_config.json:
{
"mcpServers": {
"threecommas-mcp": {
"command": "/path/to/uv",
"args": ["--directory", "/path/to/3commas-mcp", "run", "threecommas-mcp"],
"env": {
"3COMMAS_API_KEY": "your_api_key",
"3COMMAS_SECRET_KEY": "your_secret_key",
"3COMMAS_ENABLE_DESTRUCTIVE": "false"
}
}
}
}Config file locations:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
"Show me all my connected exchanges and their status"
"List all my DCA bots and their current status"
"What trading pairs are available on Binance?"See docs/conversations/ for comprehensive usage examples and scenarios.
Read-only operations only - Current implementation has zero trading risk with secure HMAC-SHA256 authentication and comprehensive error handling.
See docs/DEVELOPMENT.md for technical architecture and security details.
# Run quality checks
uv run -m black . && uv run -m ruff format . && uv run -m ruff check . && uv run -m mypy .See docs/CONTRIBUTING.md for contribution guidelines and docs/DEVELOPMENT.md for setup details.
API References - Complete 3Commas API mapping with implementation status
Tool Documentation - Detailed function references and parameters
Conversation Examples - Real-world usage scenarios
Development Guide - Technical architecture and setup
Contributing - Contribution guidelines and standards
Patterns - Implementation patterns and compliance
MIT License - see LICENSE file for details.
Trading Disclaimer: This software is for educational purposes. Cryptocurrency trading involves substantial risk. Always review configurations carefully and never trade more than you can afford to lose. Authors are not responsible for trading losses.
Issues: GitHub Issues
3Commas API: Official Documentation
Built with FastMCP and comprehensive safety-first design patterns.
Get account information for a specific account or aggregated summary.
Args: account_id: Account ID (integer) or 'summary' for aggregated data response_filter: Response detail level ("full" or "display")
Returns: Account information including settings, balance, profit metrics, and trading permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | summary | |
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that the tool returns account settings, balance, profit metrics, and trading permissions, indicating a read-only operation. No side effects or prerequisites are mentioned, but the description is adequate for safe use.
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 concise, with a clear one-line purpose, structured args and returns sections. Every sentence adds value, no 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?
With an output schema present, the description need not detail return fields exhaustively. It summarizes the return contents sufficiently. The tool has two optional parameters and the description covers purpose, parameters, and return, making it complete.
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 has 0% description coverage, but the description explicitly explains each parameter: account_id can be an integer or 'summary', and response_filter can be 'full' or 'display'. This adds significant meaning beyond the schema's title and default.
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 the resource 'account information', with two distinct modes: specific account or aggregated summary. It distinguishes from sibling tools which deal with market pairs, strategies, etc.
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 clear context for when to use the tool (to get account info for a specific ID or summary) but does not explicitly mention when not to use it or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available trading pairs across markets.
Args: market_code: Optional market filter (e.g., "binance", "okx") response_filter: Response detail level ("full" or "display")
Returns: List of trading pairs with symbols, availability, and trading parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| market_code | No | ||
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states the tool returns a list of pairs with symbols, availability, and trading parameters. It does not disclose potential behavioral traits like pagination, rate limits, or whether it is a read-only operation. Adequate but not thorough.
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 concise with clear sections (Description, Args, Returns). It front-loads the main purpose and is efficient with no wasted words. Could be slightly more structured but overall good.
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?
Despite missing parameter descriptions in schema, the description covers both parameters and the return value. With an output schema present, the return summary is sufficient. The tool has 2 optional parameters, so the description is fairly complete for its complexity.
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 0%, so the description compensates by explaining both parameters: 'market_code' as optional market filter and 'response_filter' for detail level. It adds meaning beyond the schema's empty descriptions, though it could be more precise (e.g., what values for response_filter).
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 tool's purpose: 'Get all available trading pairs across markets.' It specifies a verb ('Get') and resource ('trading pairs'), and includes an optional market filter. This distinguishes it from siblings like 'get_supported_markets' which returns markets, not pairs.
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 lists parameters but does not explicitly guide when to use this tool versus alternatives. No 'when not to use' or mention of other tools like 'get_supported_markets' for filtering by market. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available DCA bot trading strategies.
Args: response_filter: Response detail level ("full" or "display")
Returns: Complete catalog of available strategies with configuration options and compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does not disclose whether the operation is read-only, safe, or if it has side effects. It simply describes the output without addressing authentication, rate limits, or data freshness.
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 concise with three sentences: purpose, parameter, and return. It is front-loaded with the core functionality. Could include a brief note on usage, but overall it is well-structured.
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 has a single optional parameter and an output schema exists, the description is minimally adequate. It states the return type ('complete catalog') but lacks details like pagination, sorting, or whether the list is real-time. It does not leverage the output schema to reduce ambiguity.
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 adds meaning for the single parameter 'response_filter' by specifying the accepted values ('full' or 'display'), which is absent from the input schema. This helps the agent understand how to use the parameter, though it does not explain what each value returns.
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?
Description clearly states 'Get all available DCA bot trading strategies.' This is a specific verb and resource, and it distinguishes from sibling tools which focus on accounts, balances, markets, or individual bot details.
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 on when to use this tool vs alternatives. The description does not mention any preconditions, exclusions, or suggest alternative tools for different needs. It only states what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get account balance history over time.
Args: date_from: Start date in ISO 8601 format (YYYY-MM-DDTHH:MM:SS.sssZ) account_id: Account ID (integer) or 'summary' for aggregated data date_to: End date in ISO 8601 format (optional) response_filter: Response detail level ("full" or "display")
Returns: Balance history data with timestamps, USD/BTC values, and deposit amounts.
| Name | Required | Description | Default |
|---|---|---|---|
| date_from | Yes | ||
| account_id | No | summary | |
| date_to | No | ||
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by specifying return fields (timestamps, USD/BTC values, deposit amounts). However, it doesn't disclose behavioral traits like data freshness, pagination, or rate limiting. It is adequate but not comprehensive.
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 concise with a clear heading, structured Args section, and Returns section. Every sentence adds value, and the format is 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?
The description covers the main points: purpose, parameters, and return fields. With an output schema existing, it doesn't need to detail return structure. However, it could mention constraints like date range limits or pagination. Overall, it is mostly complete.
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 0%, so the description carries full burden. It explains all 4 parameters: date_from (ISO format), account_id (integer or 'summary'), date_to (optional), and response_filter (full or display). This adds significant meaning beyond the schema's type/default annotations.
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 'Get account balance history over time' with specific verb and resource. It distinguishes from sibling tools like get_account_info (which gives account details, not history) and get_dca_bot_profit_data (profit data vs. balance history).
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 explicit guidance on when to use this tool vs. alternatives. It does not mention when not to use it or compare to sibling tools like get_account_info for account-level data. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get blacklisted trading pairs for DCA bots.
Args: response_filter: Response detail level ("full" or "display")
Returns: List of blacklisted trading pairs with restrictions and configurations.
| Name | Required | Description | Default |
|---|---|---|---|
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the return type ('List of blacklisted trading pairs') but does not mention idempotency, rate limits, or safety. For a simple read operation, this is adequate but not thorough.
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 with no wasted words. It front-loads the purpose in one sentence, then lists parameters and returns in a clear, structured format. Every sentence adds value.
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 simplicity (one optional param, output schema present), the description provides a solid overview. It explains the parameter and return structure, though it could hint at when to use 'full' vs 'display'. Overall, it is nearly complete.
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 coverage is 0%, so the description must compensate. It fully explains the single parameter 'response_filter' with its purpose and valid values ('full' or 'display'), which is critical additional meaning beyond the schema's type and default.
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 'Get blacklisted trading pairs for DCA bots,' which is a specific verb and resource. It distinguishes itself from siblings like 'get_all_market_pairs' and 'get_dca_bot_details' by targeting only blacklisted pairs for DCA bots.
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 explicit guidance on when to use this tool versus alternatives. It does not mention when to use 'full' vs 'display' filter or in which scenarios blacklisted pairs are relevant, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all connected exchange accounts and wallets.
Args: response_filter: Response detail level ("full" or "display")
Returns: List of connected exchanges with account details, permissions, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It only mentions the return type (list of exchanges with details) but omits whether the operation is read-only, requires authentication, has rate limits, or any side effects. 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 very concise—only three sentences—and front-loads the core purpose. Every sentence adds necessary information (purpose, parameter meaning, return description), with no wasted 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?
Given the presence of an output schema (albeit not shown), the description need not detail return fields further. It already explains the return type and covers the one parameter. However, it could improve by clarifying when to use each response_filter value.
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 0%, so the description must add value. It does so by specifying that response_filter accepts 'full' or 'display' and controls detail level, which goes beyond the schema's bare string type with a default.
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 'all connected exchange accounts and wallets', which is specific and distinct from sibling tools like get_account_info (likely for a single account) or get_dca_bot_list. The resource is unique and well-defined.
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 like get_account_info or get_balance_history_data. There are no exclusions, context descriptions, or recommendations, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current exchange rates and trading limits for a currency pair.
Args: market_code: Exchange market code pair: Trading pair (e.g., "BTC_USDT") limit_type: Optional limit type (bot or smart_trade) response_filter: Response detail level ("full" or "display")
Returns: Exchange rates, trading limits, precision, and fee information.
| Name | Required | Description | Default |
|---|---|---|---|
| market_code | Yes | ||
| pair | Yes | ||
| limit_type | No | ||
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read operation and lists returned data, but does not disclose authentication requirements, rate limits, or side effects. Basic transparency is present, but not comprehensive.
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?
Well-structured with Args and Returns sections. Concise and to the point, though could be slightly more compact. No fluff.
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 an output schema exists, the description does not need to detail return values, but it lists them. It covers parameters and basic behavior. Lacks prerequisites or common usage scenarios, but is largely complete.
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 0%, but the description adds meaning for all 4 parameters: market_code, pair, limit_type (with examples 'bot' or 'smart_trade'), and response_filter ('full' or 'display'). This fully compensates for the lack of schema descriptions.
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 it gets current exchange rates and trading limits for a currency pair, using specific verbs and resource. It distinguishes from siblings like get_supported_markets and get_all_market_pairs.
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 explicit guidance on when to use this tool vs alternatives. The description mentions optional limit types but does not help an agent decide when to use this tool over siblings like get_supported_markets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive details for a specific DCA bot.
Args: bot_id: DCA bot unique identifier include_events: Include related events (default: False) response_filter: Response detail level ("full" or "display")
Returns: Bot configuration, active deals, trading parameters, and performance metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| bot_id | Yes | ||
| include_events | No | ||
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly implies a read-only operation via the verb 'Get' and states it returns details (configuration, deals, etc.). It does not explicitly declare non-destructiveness but is sufficiently transparent for a retrieval tool.
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 concise, using two sentences plus a clear list of args and returns. It is front-loaded with the main purpose, and every sentence adds value without 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 output schema exists, the description adequately summarizes return values. It covers all input parameters but does not address error cases (e.g., invalid bot_id) or mention that the bot must exist. Still, it is fairly complete for a get operation.
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 0%, but the description explains all three parameters: bot_id as unique identifier, include_events with default False, and response_filter with valid values 'full' or 'display'. This adds essential meaning beyond the schema's names and types.
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 tool retrieves comprehensive details for a specific DCA bot, using the verb 'Get' and specifying the resource. It distinguishes from sibling tools like get_dca_bot_list (list all bots) and get_dca_bot_profit_data (profit metrics only) by focusing on detailed information.
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 describes what the tool does and its parameters but provides no guidance on when to use this tool versus alternatives like get_dca_bot_list or get_dca_bot_profit_data. It does not give explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of DCA bots with optional filtering and sorting.
Args: account_id: Exchange account ID (0 = all accounts) strategy: Trading strategy filter (long/short) order_direction: Sort order ("ASC" or "DESC") limit: Maximum bots to return (1-1000) offset: Pagination offset from_date: Filter bots created from date (ISO format) scope: Filter scope for bot selection sort_by: Field to sort by quote: Filter by quote currency response_filter: Response detail level ("full" or "display")
Returns: List of DCA bots with configuration, status, deals, and performance data.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | ||
| strategy | No | ||
| order_direction | No | DESC | |
| limit | No | ||
| offset | No | ||
| from_date | No | ||
| scope | No | ||
| sort_by | No | ||
| quote | No | ||
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not mention side effects, rate limits, authentication requirements, pagination behavior, or data freshness. The 'Returns' line is generic and adds limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate Args and Returns sections. It lists all 10 parameters with explanations. While somewhat lengthy, it is necessary given the lack of schema descriptions. No redundant or trivial sentences are present.
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?
The description covers parameter semantics and return type at a high level. However, it lacks details on pagination behavior (e.g., how offset/limit interact), error handling, or performance implications for large result sets. The output schema is said to exist but not shown, so the description's return summary is adequate but not exhaustive.
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% schema coverage, the description compensates well by explaining each parameter's meaning (e.g., 'account_id: Exchange account ID (0 = all accounts)', 'limit: Maximum bots to return (1-1000)'). The StrategyType enum is defined in the schema, but other parameters rely entirely on the description for clarity.
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 tool retrieves a list of DCA bots with optional filtering and sorting. This directly differentiates it from sibling tools like get_dca_bot_details (single bot) and get_dca_bot_profit_data (profit data).
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 does not mention when to use get_dca_bot_details for specific bots or any exclusions. The agent is left to infer usage from parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily profit data for a specific DCA bot.
Args: bot_id: DCA bot unique identifier days: Number of days for profit data (default: 30) response_filter: Response detail level ("full" or "display")
Returns: Daily profit analytics with BTC/USD amounts and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| bot_id | Yes | ||
| days | No | ||
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read operation ('Get') and describes the return format, but does not disclose behavioral traits like idempotency, permissions, or rate limits. The return description adds value but is insufficient for full 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 concise and well-structured with Args and Returns sections. Every sentence serves a purpose, and the format is 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 simple three-parameter tool and the presence of an output schema (indicated but not shown), the description provides sufficient context: it names the return content (Daily profit analytics with BTC/USD amounts and timestamps) and covers parameters. Minor gap: no explanation of the default behavior when response_filter is 'display' vs 'full'.
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 0%, but the description fully compensates by explaining each parameter: bot_id as 'DCA bot unique identifier', days as 'Number of days for profit data (default: 30)', and response_filter as 'Response detail level ("full" or "display")'. This adds crucial meaning beyond 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 'Get daily profit data for a specific DCA bot', which is a specific verb and resource. It distinguishes from siblings like get_dca_bot_details and get_dca_bot_list, though it could be more explicit about its unique scope.
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 does not provide any guidance on when to use this tool versus alternatives or when not to use it. It only states what it does, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all supported trading markets and exchanges.
Args: response_filter: Response detail level ("full" or "display")
Returns: List of supported markets with names, features, and compatibility information.
| Name | Required | Description | Default |
|---|---|---|---|
| response_filter | No | display |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the parameter and return value (list of supported markets with names, features, compatibility). It does not disclose rate limits, caching, or other behavioral traits, but for a read-only tool this is acceptable.
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 concise with a one-line purpose, then structured Args and Returns sections. Every sentence adds value without wasted 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?
Given the tool has one optional parameter and an output schema exists, the description covers the parameter and return structure adequately. It could mention the output's format more, but completeness is high.
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 0%, but the description adds the parameter's purpose ('Response detail level') and valid values ('full' or 'display'). This fully compensates for the missing schema descriptions.
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 'Get all supported trading markets and exchanges', using a specific verb and resource. Among siblings, it distinguishes itself from tools like 'get_all_market_pairs' which focus on market pairs rather than markets/exchanges.
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 on when to use this tool vs alternatives (e.g., 'get_all_market_pairs'). There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a health check by testing API connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'tests API connectivity', implying read-only behavior without side effects. However, it doesn't detail what the health check entails (e.g., which endpoint is hit, error handling, or any potential impact). This is acceptable for a simple health check but could be clearer.
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 concise sentence with no unnecessary words, earning every character's 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 there are no parameters and an output schema exists (implied by 'Has output schema: true'), the description is sufficiently complete for a health check tool. It doesn't explain return values, but that is covered by the 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?
There are no parameters, so the description does not need to add parameter details. The baseline for zero parameters is 4, and the description appropriately conveys the tool's purpose without 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 uses the verb 'Perform' and clearly identifies the resource as 'API connectivity'. It distinguishes itself from sibling tools that are focused on retrieving specific data (e.g., account info, market pairs, bot details), making its purpose unambiguous.
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 explicit guidance on when to use this tool versus alternatives. While it's implicitly a first-step tool to verify connectivity before other calls, the description does not state when not to use it or provide any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but 'get_all_market_pairs' and 'get_supported_markets' could cause confusion as both relate to markets. Otherwise clear separation.
All tools use a consistent 'get_' prefix except 'health_check', which breaks the pattern. Naming is otherwise uniform with snake_case.
12 tools is a reasonable count for a trading API wrapper, providing a balanced set of information retrieval endpoints without being overwhelming.
The tool set lacks essential CRUD operations for DCA bots (no create, update, delete) and no trading actions (open/close deals), leaving significant gaps for a trading server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Trade 16 crypto exchanges + MetaTrader 5 from your AI assistant via one MCP connection.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/severity1/3commas-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
