Jesse MCP Server

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

With no annotations provided, the description carries the full burden. It discloses the Bayesian method and that it 'tests many parameter combinations,' implying iterative behavior. However, it fails to disclose operational characteristics like whether this is asynchronous, computationally expensive, or state-modifying—critical gaps for a 14-parameter optimization 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 second sentence ('Automatically tests many parameter combinations...') largely repeats the first sentence's meaning without adding new information. The example is valuable but formatted as a dense text block with dashes rather than clear structure. Overall adequate but contains 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?

Despite having an output schema (reducing the need to describe returns), the description is incomplete given the tool's complexity. With 14 parameters including trading-specific ones (leverage, fee, exchange_type) and 0% schema coverage, the description should document critical parameters or data formats beyond just the param_space example.

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%, requiring heavy compensation. The description provides an example illustrating param_space structure (ranges as arrays) and metric naming, but leaves 12 other parameters (symbol, timeframe, dates, exchange, leverage, fees, etc.) completely undocumented with no format hints or domain context.

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 auto-optimizes strategy hyperparameters using Bayesian optimization, providing specific verb, resource, and algorithmic method that distinguishes it from sibling optimization tools like backtest_optimize_parameters or optimization_walk_forward.

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?

Provides a concrete example showing param_space structure and metric selection, which offers implicit guidance. However, it lacks explicit when-to-use guidance comparing this to sibling optimization tools (e.g., optimization_batch, optimization_walk_forward) or prerequisites for the strategy parameter.

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