dotbugi-mcp

Overview Schema Source Related Servers Discussions Admin

로컬 음성 인식(ASR) 설치 시작

asr_install

Idempotent

Install the local Qwen3-ASR runtime used by lecture transcription as a resumable background job, with SHA-256-verified downloads; progress is tracked separately.

Instructions

transcribe_lecture 가 쓰는 로컬 음성 인식(Qwen3-ASR) 런타임을 ~/.cache/dotbugi-mcp/asr 에 설치하는 백그라운드 작업을 시작하고 바로 돌아온다. 수 GB 를 받으며 모든 파일은 코드에 고정된 sha256 으로 검증한다. 진행은 asr_status. 중단돼도 다시 부르면 이어 받는다.

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_install"
  }
}

Input Schema

Name	Required	Description	Default
`gpu`	No	NVIDIA GPU(Linux·WSL) 런타임. uv 가 필요하다
`model`	No	모델 (기본 0.6b). 1.7b 는 gpu 와 함께만

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 24, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare non-read-only, non-destructive, idempotent, open-world. The description adds the details that actually change agent behaviour: the call returns immediately instead of blocking, it downloads several GB, every file is verified against a sha256 pinned in code, progress is observed elsewhere, and re-invocation resumes. That is exactly the context annotations cannot carry.

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 action and scope come first, followed by only the facts that matter: download size, verification, progress channel, resumability. Four short sentences with no filler, though the long opening sentence could be split for faster scanning.

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 fire-and-forget background installer with no output schema, the description covers return semantics (returns immediately), cost (several GB), integrity (sha256), monitoring (asr_status) and recovery (resume). Nothing an agent needs in order to invoke it safely is missing.

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 description coverage is 100% and the schema already explains gpu (NVIDIA, requires uv) and model (defaults to 0.6b; 1.7b only with gpu). The description adds no parameter-level meaning of its own, 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: starts a background job that installs the local Qwen3-ASR runtime at ~/.cache/dotbugi-mcp/asr. It also ties the tool to the sibling that consumes the runtime (transcribe_lecture) and names asr_status for progress, so an agent can place it in the workflow without opening a 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?

Implicit routing is clear: this is the prerequisite install for transcribe_lecture, progress goes to asr_status, and re-calling resumes an interrupted download rather than restarting. It does not explicitly say when not to call it (for example, when the runtime is already present, or which sibling removes it), so it falls short of full alternative coverage.

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