Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

get_tentacle_config

Retrieve a tentacle's current configuration, schema, and display metadata to inspect its setup before making changes.

Instructions

Fetch one tentacle's current configuration, schema, and display metadata.

Maps to GET /config_tentacle_edit_details/<tentacle> -- see this module's docstring for the spec correction (the spec named GET /config_tentacle, which has no JSON response path at all). tentacle is the tentacle's class name (e.g. "DailyTradingMode"), confirmed live against the OctoBot 2.1.1 test instance.

Returns OctoBot's own JSON body unchanged (NFR-8): {"name": str, "config": object, "displayed_elements": object}. config holds this tentacle's actual configuration values (the same values update_tentacle_config's patch argument would merge into); displayed_elements is the JSON-schema-shaped UI-form metadata OctoBot's own config page renders from, passed through unsimplified.

Read-only, not confirm-gated. An unknown tentacle name raises an uncaught exception inside OctoBot's model layer, surfaced as OctoBotServerError (confirmed live: HTTP 500, plain-text body "Can't find tentacle: <tentacle>", despite a Content-Type: application/json header that doesn't actually describe the body -- handled via this module's _extract_error_text, same as update_tentacle_config).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tentacleYes

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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it declares read-only/non-confirm-gated behavior, documents the exact response shape and semantics, discloses the live-confirmed HTTP 500 error for unknown tentacle names and the error-body mismatch, and even explains the internal error-extraction handling.

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 front-loaded with the main purpose, then structured into endpoint mapping, return shape, and error behavior. It is longer than typical, and a few internal implementation details (module docstring reference, NFR-8 label, Content-Type header nuance) are beyond what an agent strictly needs, but the density is still justified by the tool's complexity.

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 single-parameter read tool with no annotations and no output schema, the description is remarkably complete: it covers the parameter format, response fields and their meaning, the read-only safety profile, and the failure mode without requiring the agent to make assumptions.

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?

The schema offers no description for the single required parameter, but the description fully compensates by stating that tentacle is the tentacle's class name and providing a concrete example ('DailyTradingMode'). This is exactly the semantic information an agent needs to construct a valid call.

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: 'Fetch one tentacle's current configuration, schema, and display metadata.' This clearly distinguishes it from the sibling list_tentacles (which lists tentacles) and update_tentacle_config (which modifies configuration), and the endpoint mapping reinforces the exact operation.

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 makes the read-only purpose and relationship to update_tentacle_config clear, implying when to use this tool versus the update sibling. However, it does not explicitly state exclusions such as 'use list_tentacles to enumerate all tentacles' or 'use update_tentacle_config when modification is needed.'

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