Skip to main content
Glama
soil-dev

capsulemcp

by soil-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

remove_track

Destructive

Remove a track from its entity, also deleting auto-tasks the track created. Confirm to permanently remove; copy any needed task details first.

Instructions

Remove a track instance from its entity. Capsule also deletes the auto-tasks the track created when it was applied; copy any task details you need before removing the track. Requires confirm=true. Idempotent on retry: response is {removed: true, alreadyRemoved: false, trackId} on a fresh remove or {removed: true, alreadyRemoved: true, trackId} if the track was already gone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
confirmYesMust be set to true. Removes the track instance from its entity. **Capsule also deletes the auto-tasks the track created when it was applied** — they go with the track and become unreachable (404 on GET /tasks/{id}, gone from list_tasks on the parent entity). If you need any of those tasks to outlive the track, copy their content into fresh tasks (or use the web UI) before calling remove_track.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.0
    • changedInput schema / required
      Previous value: -[
-  "confirm"
-]New value: +[
+  "id",
+  "confirm"
+]
  2. Changed2 schema fields changedv2.1.2
    • addedInput schema / properties / id
      Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
    • removedInput schema / properties / trackId
      Removed value: -{
-  "exclusiveMinimum": 0,
-  "maximum": 9007199254740991,
-  "type": "integer"
-}
  3. Addedv1.7.0
  4. Removedv1.6.2
  5. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Despite annotations already indicating destructiveHint=true, the description adds valuable detail: removing the track also deletes its auto-tasks, they become unreachable (404 on GET /tasks/{id}), and users should copy needed details first. It also discloses idempotency and exact response shapes for fresh vs already-removed calls, which annotations cannot convey.

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?

The description is three sentences with no filler: core action, destructive side effect, and prerequisite/idempotent response. The most important operational facts are front-loaded, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with no output schema, the definition covers the essential ground: side effects, confirmation requirement, retry semantics, and response format. The only material gap is that id is not explicitly defined as the track-instance identifier, which could cause confusion in a tool with many id-bearing siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The confirm parameter is thoroughly documented in the schema, so the description adds little there. However, the id parameter has no schema description, and the main description only indirectly indicates that id refers to the track instance via the response field trackId and the phrase 'Remove a track instance.' This is adequate but leaves some inference to the agent.

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 object: 'Remove a track instance from its entity.' This clearly distinguishes remove_track from siblings like apply_track, update_track, get_track, and list_entity_tracks. It states both the operation and the resource affected without ambiguity.

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 gives clear context for use: removing a track instance from an entity. It also provides a critical precondition ('Requires confirm=true') and describes retry behavior, which guides correct invocation. It does not explicitly name alternatives or when-not-to-use, but the purpose is specific enough that an agent can select it appropriately among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools