dotbugi-mcp

Overview Schema Source Related Servers Discussions Admin

ASR 런타임 삭제

asr_remove

DestructiveIdempotent

Deletes the local speech-recognition runtime after explicit user approval, refuses while installation or transcription is active, and supports token-based confirmation for clients without dialogs.

Instructions

로컬 음성 인식 런타임(/root/.cache/dotbugi-mcp/asr)을 삭제한다. 사용자가 클라이언트 확인 창에서 직접 승인해야 지운다. 설치·STT 작업이 실행 중이면 거절한다. 확인 창이 없는 클라이언트면 confirmToken 을 돌려준다 — 사용자 동의를 받은 뒤에만 그 토큰으로 다시 호출한다.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "asr_remove"
  }
}

Input Schema

Name	Required	Description	Default
`confirmToken`	No	확인 창을 띄울 수 없는 클라이언트에서 첫 호출이 돌려준 일회용 확인 토큰. 사용자에게 목록을 보여주고 동의를 받은 뒤에만 넣는다

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag destructiveHint and idempotentHint, but the description adds real context beyond them: the exact directory destroyed, the requirement of direct user approval in a client dialog, refusal while install/STT jobs run, and the one-time confirmToken handshake. That is exactly the operational detail an agent needs before invoking a destructive tool.

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?

Four short sentences, each carrying distinct information: target, approval requirement, refusal condition, token fallback. The destructive target is front-loaded and nothing is redundant.

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?

A destructive, zero-required-param tool with no output schema — the description covers the safety gate, the failure mode, and the two-step consent flow completely enough for correct invocation.

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?

Schema description coverage is 100% and the single confirmToken param is already documented in the schema. The description nonetheless adds the invocation protocol around it: the token comes from a first call on non-dialog clients, and it must only be supplied after user consent.

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 a precisely scoped resource (로컬 음성 인식 런타임, with the exact path /root/.cache/dotbugi-mcp/asr). This clearly separates it from siblings like asr_install and asr_status without opening any schema.

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?

Explicitly names the blocking conditions (설치·STT 작업이 실행 중이면 거절한다) and describes the fallback path for clients without a confirmation dialog. It doesn't explicitly route to a sibling (e.g., asr_install for the inverse operation), which keeps it from a 5.

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