Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

check_accounts_compatible

Verify that each named exchange's stored credentials work against its existing OctoBot account configuration, with no secret values needed.

Instructions

Check whether each named exchange's already-configured account is usable.

Maps to POST /api/are_compatible_accounts. OctoBot's real request body for this route is more general than this tool's input -- it expects a dict keyed by exchange, each value an object with exchange/apiKey/apiSecret/apiPassword/sandboxed fields meant for OctoBot's own "test these credentials" UI form (confirmed against OctoBot source models/configuration.py::are_compatible_accounts() and octobot_commons.constants, [V] this session -- this is a correction of this tool's spec entry, which only names exchange_names; see the implementation report for detail).

This tool deliberately narrows that to just exchange_names and always submits OctoBot's own masked-placeholder value ("******") for the credential fields, so it checks compatibility using whatever credentials are already stored on the OctoBot instance for each named exchange, never a credential supplied through this call. Confirmed from source: OctoBot only treats a non-placeholder value as a real credential update (_is_real_exchange_value) and otherwise falls back to the exchange's already-configured encrypted value, so a placeholder-only request checks the existing configuration without ever transmitting or requiring a real credential. No credential value passes through this tool's input or output. Read-only in effect, not confirm-gated. Returns OctoBot's own JSON body unchanged (NFR-8).

CAVEAT: sandboxed is currently hardcoded to False for every exchange checked, regardless of how that exchange is actually configured on the instance. It is unconfirmed whether OctoBot's credential-fallback path uses this value to pick which environment (testnet vs. production) to validate stored credentials against; if it does, a genuinely sandboxed exchange may be checked against the wrong environment. Treat this tool's result with caution for any exchange you know to be configured in sandbox/testnet mode until this is confirmed against source.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
exchange_namesYes

Schema Changelog

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

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden, and it excels: it reveals the underlying endpoint, explains the masked-placeholder credential behavior, confirms no credential passes through input/output, states it is read-only in effect, and discloses the sandboxed-hardcoded caveat. This is exemplary transparency.

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 longer than typical but every paragraph adds value, especially given the absence of annotations and the nuanced behavior. It front-loads the purpose and then provides necessary caveats. Slight over-inclusion of source-verification detail prevents a 5 for conciseness.

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 no annotations, no output schema, and a single parameter, the description is remarkably complete: it explains the request mapping, credential handling, return behavior, and a serious caveat about sandbox mode. An agent has sufficient context to invoke it correctly and interpret results.

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 description coverage is 0%, so the description must compensate. It clearly explains that exchange_names is the list of exchanges to check compatibility for, and that the tool deliberately narrows its input to just this field. It doesn't specify accepted name formats or edge cases, but the core semantic is well-covered.

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 and resource: 'Check whether each named exchange's already-configured account is usable.' This clearly distinguishes it from sibling tools like update_exchange_credentials or get_exchange_details by emphasizing it validates existing stored credentials rather than accepting new ones. The scope is unambiguous.

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 clearly implies when to use this tool: to verify compatibility of already-configured exchanges without supplying credentials. It explicitly states that credentials cannot be passed through this call and that it falls back to stored credentials. However, it does not explicitly name an alternative tool or provide a direct when-not-to-use statement, so it falls short of full 5.

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