Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

import_data_file

Import an existing OctoBot-format historical data file to make it available for analysis, skipping the need to collect data from an exchange.

Instructions

Upload an existing OctoBot-format historical data file without collecting it via an exchange.

Not confirm-gated (ADR-0003/FR-26): creates new state, destroys nothing. Maps to POST /data_collector?action_type=import_data_file (multipart file field, mirroring create_profile(mode="import_file")'s existing pattern exactly: base64-decode, then a multipart upload).

A confirmed OctoBot-side limitation, not a bug in this tool: this route ALWAYS responds HTTP 200 with the full re-rendered /data_collector page, on both a genuinely saved file and a silently rejected one (confirmed live this session with garbage bytes -- no file appeared in list_data_files() afterward, and the 200 response body carried no inspectable error text anywhere) -- the same invisible-at-the-HTTP-level outcome octobot_mcp.tools.profiles._create_profile_import_file already documents for create_profile(mode="import_file"). This tool therefore determines the outcome via a before/after list_data_files() diff, exactly like that tool does for profiles.

Output: {"filename": str, "imported": true, "message": str}.

Errors: DataFileImportFailedError if file_base64 isn't valid base64, or if no new file appears in list_data_files() after the upload (OctoBot silently rejected it).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filenameYes
file_base64Yes

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, the description carries full behavioral burden and does so impressively. It discloses the non-confirm-gated behavior, the create-nothing-destroy-nothing state model, the OctoBot silent-rejection limitation (HTTP 200 even on failure), and the before/after list_data_files() verification strategy.

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 long, but nearly every sentence carries essential caveats or implementation context that cannot be inferred from the schema. It is front-loaded with the core purpose, then systematically covers behavior, output, and errors. Minor redundancy around the create_profile analogy could be trimmed.

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?

For a tool with no output schema and no annotations, the description covers everything an agent needs: the exact invocation pattern, the multipart format, the verification mechanism, the output contract, and the error conditions. It even references the relevant sibling verification tool (list_data_files).

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 clarify the two parameters. It explains that file_base64 should be valid base64 and is base64-decoded into a multipart 'file' field, and it shows filename in the output shape. This adds real meaning beyond the raw schema, though a direct per-parameter definition would be slightly stronger.

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 first sentence states a specific verb ('Upload'), a specific resource ('existing OctoBot-format historical data file'), and a clear exclusion ('without collecting it via an exchange'). It unambiguously distinguishes this import operation from data-collection workflows, so an agent can identify the tool immediately.

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 clarifies when the tool applies: when an OctoBot-format data file already exists and should not be collected via an exchange. It does not explicitly name sibling alternatives like start_data_collection, but the 'without collecting it via an exchange' framing plus the route mapping provides enough usage context.

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