Skip to main content
Glama
Sign In
statica-mcp

statica-mcp

Official
by SuresoftTechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Cancel an unfinished connection

statica_bootstrap_abort
Destructive

Cancel an unfinished project connection by restoring files kept by the bootstrap guard, then deleting the wrapper and workspace; ready workspaces are refused. Confirm first.

Instructions

Undo an unfinished connection: restore files kept by statica_bootstrap_guard, then delete the wrapper and workspace. Refuses ready workspaces. For IDE/GUI substitution it cannot undo the IDE settings - walk the user through the guide's revert steps too. If ok is false the project is still modified: relay restore.failed and snapshotDir verbatim. Confirm with the user first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectDir": "<projectDir>"
    },
    "name": "statica_bootstrap_abort"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonNoWhy the connection is being cancelled.
projectDirYesAbsolute path of the project directory being analyzed (usually the session's working directory).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description goes well beyond them: it names exactly what is destroyed (wrapper and workspace) versus restored (files kept by statica_bootstrap_guard), states the refusal condition, and flags partial-failure semantics when ok is false. The only gap is that it does not say whether the restore step is recoverable if it fails midway.

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?

Four sentences, front-loaded with what the tool does before operator instructions, and every sentence carries a distinct fact (action, refusal, gap, failure relay, confirmation). The failure-handling sentence is slightly compressed and reads awkwardly, which keeps it just under full marks.

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?

There is no output schema, and the description compensates by naming the operative return fields (ok, restore.failed, snapshotDir) and instructing verbatim relay on failure. Combined with the refusal condition and confirmation requirement, an agent has enough to call this destructive tool safely; only mid-operation recoverability remains unspecified.

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?

Schema coverage is 100%, so projectDir's absolute-path meaning and reason's purpose are already fully documented in the schema. The description implies projectDir via 'files kept by statica_bootstrap_guard' but adds no new syntax, format, or validation detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Undo an unfinished connection') and then enumerates the exact actions: restore files kept by statica_bootstrap_guard, delete the wrapper and workspace. The clause 'Refuses ready workspaces' sharply separates it from statica_bootstrap_finish, so an agent can pick between them without opening either schema.

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

Usage Guidelines5/5

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

Gives a clear when (cancelling an unfinished connection), a when-not (ready workspaces are refused), and a prerequisite ('Confirm with the user first'). It also routes the agent to the guide's revert steps for the IDE-substitution case that this tool cannot undo, which is an explicit handoff to another path.

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