Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

delete_profile

Permanently delete a trading profile after explicit confirmation. Returns a structured refusal if not confirmed, and verifies deletion to avoid false success.

Instructions

Permanently delete a profile. Confirm-gated (ADR-0003): irreversible.

If confirm is not exactly true, no OctoBot call is made at all -- this returns require_confirmation's structured refusal (a normal return, not an error) instead.

Once confirmed, maps to POST /profiles_management/remove with JSON body {"id": profile_id} (confirmed against source controllers/configuration.py's "remove" action, which reads exactly flask.request.get_json()["id"] -- the spec's documented body shape is correct here, unlike update_profile's in milestone 5).

Two failure modes confirmed against source (models/profiles.py::remove_profile), both surfaced as ProfileDeleteRejectedError:

  • profile_id is the currently-selected/active profile: OctoBot itself rejects this ("Can't remove the active profile"), returned as HTTP 400 with that exact string as the JSON body.

  • profile_id names a profile whose removal a ProfileRemovalError blocks (e.g. an in-use profile): also HTTP 400, wrapping that error's text. An unrecognized profile_id isn't checked by remove_profile before this tool ever reaches OctoBot: it's rejected locally as ProfileNotFoundError (via the same pre-fetched scrape used to look up name, below) rather than let OctoBot's own uncaught KeyError produce an HTTP 500.

Extra safety check, not strictly required by OctoBot's own response but added anyway: OctoBot's 200 success body for this action is the same uninformative literal string "Profile created" copied from the unrelated duplicate action (confirmed against source) -- not "Profile deleted" or anything that actually confirms removal. Given that copy-paste bug, this tool re-checks via the same scrape list_profiles/get_profile use that profile_id is genuinely gone afterward, raising ProfileDeleteRejectedError (not trusting the 200) if it is still present.

The profile's name is captured from a scrape taken before deletion (per this tool's spec entry), since after a real deletion it can no longer be found by scraping.

Output on success: {"profile_id": str, "name": str, "deleted": true}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNo
profile_idYes

Schema Changelog

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

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description fully carries the behavioral burden. It discloses irreversibility, the confirm gate, that no OctoBot call is made without confirmation, two failure modes, local rejection of unknown IDs, the OctoBot success-body bug, the extra post-deletion safety check, and name capture before deletion. This is exceptionally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though lengthy, the description is well-structured and front-loaded with the core action. Each paragraph addresses a distinct concern: confirmation behavior, API mapping, failure modes, safety verification, and return shape. The detail about source-code confirmation and the copy-paste bug is justified given the tool's destructive and surprising behavior.

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 is remarkably complete. It covers exact invocation conditions, error modes, success output shape, and the fallback safety check. There are no significant gaps that would prevent an agent from calling this tool correctly.

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?

Schema description coverage is 0%, but the description compensates fully. It explains that confirm must be exactly true, describes what happens if false, defines profile_id semantics (active profile, blocked removal, unrecognized ID), and even documents the JSON body shape sent to the API.

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 'Permanently delete a profile', which is a specific verb+resource statement. It goes on to specify the exact endpoint and body mapping, and is clearly distinct from sibling tools like create_profile, update_profile, and select_profile.

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 establishes when this tool applies: confirm-gated, irreversible profile deletion, with a structured refusal if confirm is not exactly true. It does not explicitly enumerate alternatives or when-not-to-use, but the uniqueness of the destructive operation makes the usage context unambiguous.

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