Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

export_logs

Export OctoBot's full logs as a base64-encoded zip archive to troubleshoot or analyze bot activity.

Instructions

Export OctoBot's full logs as a zip archive, base64-encoded.

Maps to GET /export_logs -- the exact same binary-file-download pattern as octobot_mcp.tools.profiles.export_profile (flask.send_file, not JSON): this tool bypasses octobot_mcp.client.request_json for the same reason and base64-encodes the raw response body. See this module's docstring for the source/live verification detail, including why the downloaded filename (unlike export_profile's) is not dynamic.

filename is read from the response's Content-Disposition header via the shared octobot_mcp.tools._shared._parse_content_disposition_filename helper -- the same one export_profile uses -- rather than hardcoding OctoBot's own literal "logs_export.zip" locally.

On failure, OctoBot's own controller (confirmed against source) catches every export exception internally, flashes an HTML-only session message, and 302-redirects back to /logs -- never a 4xx/5xx status. This tool cannot distinguish that redirect from a genuine success at the HTTP-status level alone, so -- the same fail-loud approach export_profile uses for its own missing-header case -- it raises OctoBotMalformedResponseError whenever no parsable filename is found in the response, rather than ever returning a fabricated filename or empty content.

Output: {"filename": str, "content_base64": str}. Read-only, not confirm-gated (ADR-0003).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

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

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: base64 encoding, bypass of request_json, Content-Disposition filename parsing, redirect-on-failure behavior, and the explicit OctoBotMalformedResponseError fallback. It also discloses read-only, non-confirm-gated behavior via ADR-0003.

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 necessary for a zero-parameter tool, but it is front-loaded with the core purpose and each paragraph addresses a meaningful concern (wire format, filename handling, failure semantics, output shape). Some meta-references to module docstrings and source verification could be trimmed without loss.

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 output schema and no annotations, the description fully specifies the return format, error behavior, and read-only/gating status. An agent has everything needed to invoke and interpret the tool correctly.

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 tool has zero parameters, so the baseline is 4 and there is nothing for the description to add about arguments. It instead documents the output contract, which is the relevant semantic content for this tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a clear verb+resource statement: 'Export OctoBot's full logs as a zip archive, base64-encoded.' The format and scope are explicit, but it never contrasts the tool with sibling get_logs, relying on the name and first sentence for differentiation.

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 implies usage—call this when a full logs export is needed—and draws a useful analogy to export_profile. It does not, however, state when to prefer this over get_logs or mention any exclusions/prerequisites.

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