Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

export_profile

Export a trading profile as a base64-encoded zip archive for backup or transfer. Returns the profile ID, original filename, and encoded content.

Instructions

Export a profile as a zip archive, base64-encoded.

Maps to GET /profiles_management/export?profile_id=<profile_id> (spec [V]; profile_id confirmed as the exact query-param name against source controllers/configuration.py, action "export" -- not id). This route returns the zip's raw bytes directly (flask.send_file), not JSON, so this tool bypasses octobot_mcp.client.request_json (same reason as _fetch_profiles_selector_html) and base64-encodes the raw response body instead.

filename is read from the response's Content-Disposition header (confirmed live: attachment; filename=<profile name>_<YYYYMMDD-HHMMSS>.zip, quoted only when the profile name isn't already a single HTTP token -- e.g. it contains a space -- per RFC 6266/2183; both forms confirmed live, see octobot_mcp.tools._shared._parse_content_disposition_filename, moved there in milestone 13 so octobot_mcp.tools.tentacles.export_logs shares this same implementation) rather than reconstructed locally, so it always matches exactly what OctoBot named the file. Raises OctoBotMalformedResponseError if that header is missing or unparseable -- never returns a fabricated filename.

Output: {"profile_id": str, "filename": str, "content_base64": str}. Read-only, not confirm-gated (ADR-0003). An unknown profile_id raises an uncaught NoProfileError inside OctoBot (HTTP 500, confirmed live with the Content-Type: application/json request header this call always sends for a readable error message).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profile_idYes

Schema Changelog

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

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It reveals that the response is raw bytes, that the body is base64-encoded, that filename is derived from Content-Disposition rather than fabricated, that malformed headers raise OctoBotMalformedResponseError, and that unknown profile_id yields an HTTP 500 with NoProfileError. 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 definition is front-loaded with a clear purpose and organized into focused paragraphs. It is verbose, and some implementation archaeology such as 'moved there in milestone 13' and RFC references is more detail than an agent needs to invoke the tool. Still, the structure is logical and the length mostly serves genuine behavioral transparency rather than filler.

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?

Despite the absence of annotations and output schema, the description defines the exact output shape, error behavior, read-only nature, confirmation-gating status, and endpoint mapping. An agent has everything needed to invoke the tool correctly and interpret its result.

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?

The schema provides only the parameter name with no description, so schema coverage is 0%. The description compensates by confirming the exact query-param name (profile_id, not id) and by documenting the failure mode for an unknown profile_id. It does not elaborate on where to obtain a valid profile_id or its format, but for a single self-explanatory parameter this is sufficient added meaning.

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 opening sentence states a specific verb and resource: 'Export a profile as a zip archive, base64-encoded.' This unambiguously distinguishes it from sibling profile tools like get_profile, which retrieves profile details rather than producing a downloadable archive. The endpoint mapping reinforces the purpose without introducing ambiguity.

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

Usage Guidelines3/5

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

The description clearly implies the tool is for exporting a profile archive, and it notes the operation is read-only and not confirm-gated. However, it does not explicitly say when to prefer this over alternatives such as get_profile or list_profiles, nor does it state any exclusions or prerequisites. Usage context is present but only by implication.

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