Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

update_evaluator_config

Update the active evaluator configuration for the current trading profile by enabling or disabling specific evaluators, with an option to deactivate all unlisted evaluators.

Instructions

Update the current profile's evaluator-activation config.

Maps to POST /config, JSON body {"evaluator_config": patch, "deactivate_others": deactivate_others} -- TWO top-level keys, never one nested under the other -- see this module's docstring for the full source-verified derivation of this exact shape and the request-body key's literal value (EVALUATOR_CONFIG_KEY = "evaluator_config", resolving the tool spec's/requirements doc's open question #12). patch is submitted as-is, unwrapped, mapping evaluator class names to a boolean (or "true"/"false" string) activation state -- the same shape update_trading_config submits under its own key, since both reach the same underlying models.update_tentacles_activation_config.

deactivate_others (default False, resolving open question #13): when True, every OTHER currently-active evaluator NOT named in patch is force-disabled -- confirmed by tracing models. update_tentacles_activation_config into TentaclesSetupConfiguration. update_activation_configuration/_deactivate_other_evaluators's own body (see this module's docstring for the full trace); this only ever touches tentacles whose type is one of the four evaluator subtypes (technical-analysis/social/real-time/scripted) -- trading modes and strategies are never affected by this flag. False (this tool's default) is purely additive: only the evaluators named in patch have their activation state changed, every other tentacle is left untouched.

patch's keys are evaluator CLASS NAMES, not display names -- e.g. "RSIMomentumEvaluator", "BBMomentumEvaluator", "DoubleMovingAverageTrendEvaluator", "MACDMomentumEvaluator", "SuperTrendEvaluator" are real examples confirmed against the OctoBot 2.1.1 test instance's default evaluator set. Use this module's own list_evaluators() (task 19, ADR-0009 -- reversed to GO by explicit user decision after originally recommending NO-GO here) to discover every evaluator's exact class name and current activation state: its name field is exactly the string this tool's patch keys must equal, closing the loop structurally. get_tentacle_config(name) does NOT expose activation state (confirmed live: its config field holds only that evaluator's own tunable parameters, e.g. RSI thresholds -- never an enabled/disabled flag).

Output: {"evaluator_updated_config": <passthrough of OctoBot's own echoed value for this key from its success response>} -- matches the route's own response shape (NFR-8), by direct analogy to update_trading_config's own confirmed {"trading_updated_config": ...} shape (same response envelope, different key extracted).

Not confirm-gated (ADR-0003): mutates which evaluators are active, does not destroy data, expose credentials, or enable live trading. Raises EvaluatorConfigUpdateRejectedError on any non-2xx response -- see this module's docstring for why, for this tool's own request shape, OctoBot's own error text is confirmed to always be an empty string in practice (the evaluator_config branch never populates the route's own err_message variable, exactly like the trading_config branch update_trading_config documents).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patchYes
deactivate_othersNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses mutation, the default additive behavior, the side effects of deactivate_others, that only evaluator subtypes are affected and never trading modes/strategies, that the tool is not confirm-gated, that it raises EvaluatorConfigUpdateRejectedError on non-2xx responses, and that the error text is empty 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.

Conciseness4/5

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

The description is dense and information-rich, but long. References to module docstrings and open questions add provenance yet could be trimmed. It is front-loaded with purpose and endpoint mapping, and every paragraph contributes actionable detail.

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 zero annotations, no output schema, and a deceptively simple input schema, the description is remarkably complete. It covers the exact request-body shape, parameter derivation, example class names, output envelope, error behavior, and the discovery path through list_evaluators().

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

Parameters5/5

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. It explains that patch keys must be evaluator class names with real examples, values can be booleans or 'true'/'false' strings, the patch is submitted as-is unwrapped, and deactivate_others default and semantics are thoroughly described.

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 opens with a specific verb-resource pair: 'Update the current profile's evaluator-activation config.' It further distinguishes itself by mapping to POST /config and explaining that patch keys are evaluator class names, so it cannot be confused with sibling tools like update_trading_config or update_tentacle_config.

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 strong practical guidance: use list_evaluators() to discover exact class names and current activation states, and explicitly warns that get_tentacle_config does NOT expose activation state. It also clearly defines when deactivate_others=True versus False. It does not explicitly state a when-not-to-use caveat against sibling update tools, but the contextual signal is strong.

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

Install Server

Other Tools