Skip to main content
Glama
drasticstatic

hummingbot-mcp

by drasticstatic
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

manage_executors

Control trading executors by creating, searching, and stopping them, while managing saved default configurations for order, position, grid, DCA, and LP executors.

Instructions

Manage trading executors: create, search, stop, and configure preferences.

This is the DEFAULT tool for ALL trading operations. Use progressive disclosure to get
the full guide and config schema for any executor type before creating.

Executor Types (pass executor_type with no action to see full guide + schema):
- order_executor: Buy/sell orders (MARKET, LIMIT, LIMIT_MAKER, LIMIT_CHASER)
- position_executor: Directional positions with SL/TP management
- grid_executor: Grid trading for range-bound markets
- dca_executor: Dollar-cost averaging with scheduled levels
- lp_executor: CLMM LP positions on Meteora/Raydium (use explore_dex_pools first)

Actions:
- (none) + executor_type → Show full guide, config schema, and saved defaults
- create + executor_config → Create executor (merged with saved defaults)
- search → List/filter executors (add executor_id for detail)
- stop + executor_id → Stop executor (with keep_position option)
- get_logs + executor_id → Get logs (active executors only)
- get_preferences / save_preferences / reset_preferences → Manage saved defaults
- positions_summary → View all positions (add connector_name + trading_pair to filter)
- clear_position + connector_name + trading_pair → Clear externally-closed position

Args:
    action: Action to perform. Leave empty to see executor types or config schema.
    executor_type: Type of executor. Provide alone to see its full guide and config schema.
    executor_config: Configuration for creating an executor. Required for 'create' action.
    executor_id: Executor ID for 'search' (detail), 'stop', or 'get_logs' actions.
    log_level: Filter logs by level - 'ERROR', 'WARNING', 'INFO', 'DEBUG' (for get_logs).
    account_names: Filter by account names (for search).
    connector_names: Filter by connector names (for search).
    trading_pairs: Filter by trading pairs (for search).
    executor_types: Filter by executor types (for search).
    status: Filter by status - 'RUNNING', 'TERMINATED' (for search).
    cursor: Pagination cursor for search results.
    limit: Maximum results to return (default: 50, max: 1000).
    keep_position: When stopping, keep the position open instead of closing it (default: False).
    save_as_default: Save executor_config as default for this executor_type (default: False).
    preferences_content: Complete markdown content for the preferences file. Required for 'save_preferences'.
    account_name: Account name for creating executors (default: 'master_account').
    connector_name: Connector name for position filtering or clearing.
    trading_pair: Trading pair for position filtering or clearing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNo
executor_typeNo
executor_configNo
executor_idNo
log_levelNo
account_namesNo
connector_namesNo
trading_pairsNo
executor_typesNo
statusNo
cursorNo
limitNo
keep_positionNo
save_as_defaultNo
preferences_contentNo
account_nameNo
connector_nameNo
trading_pairNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.4

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It describes many behaviors: progressive disclosure for executor types, default merging with saved defaults, pagination with cursor and limit, stop with keep_position option, and log retrieval only for active executors. It does not mention rate limits or authentication requirements, but covers core behavioral traits well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose but well-structured with headings, bullet points, and clear sections. It front-loads the main purpose and then details actions and parameters. Every sentence provides useful information. However, it could be more concise; the list of executor types and actions could be summarized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (18 parameters, multiple actions, no output schema, no annotations), the description is remarkably complete. It covers all actions, parameters, defaults, executor types, and even references sibling tools (explore_dex_pools). It explains progressive disclosure and preferences management comprehensively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 explains every parameter in the Args list, including defaults (e.g., limit default 50, keep_position default false). It clarifies action-specific requirements (e.g., 'executor_config required for create'). Some parameters like 'cursor' and 'log_level' are explained sufficiently. The description adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Manage trading executors: create, search, stop, and configure preferences.' It explicitly labels itself as the 'DEFAULT tool for ALL trading operations,' which distinguishes it from sibling tools like manage_bots or manage_controllers. The listing of executor types and actions provides specific context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit instructions: 'Use progressive disclosure to get the full guide and config schema for any executor type before creating.' It explains when to use different actions (e.g., 'executor_type with no action → Show full guide'). However, it does not explicitly state when NOT to use this tool or provide clear comparisons with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools