Skip to main content
Glama

start_bugfix

Read-only

Initiates a structured bug fixing workflow. Analyzes error context to identify root cause, applies fix, and runs validation tests.

Instructions

当用户需要找问题、修 bug、排查异常时使用。默认按 SRC-8(TBP-inspired)编排:收敛边界→真因工作表→修复→测试→记忆沉淀。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docs_dirNo文档目录。可选,默认 docs
descriptionNoBug 描述(与 error_message 同义;仅传 description 时自动作为错误信息)
stack_traceNo堆栈跟踪。可选
code_contextNo相关代码。可选
feature_nameNo关联功能规格名(对应 docs/specs/<feature_name>/)。提供后或能自动识别时,修复闭环会插入 check_spec 闸门
project_rootNo项目根目录绝对路径。建议显式传入;docs_dir 等相对路径参数应统一相对该项目根目录解析,避免依赖客户端 cwd。
analysis_modeNo分析方法。默认 src8;tbp8 为兼容别名
error_messageNo错误信息(可与 description 二选一)
loop_max_roundsNo需求 loop 最大轮次(默认 2)
template_profileNo模板档位:auto(默认,自动选择 guided/strict)、guided(普通模型友好)或 strict(结构更紧凑)
requirements_modeNo需求模式:steady(默认,直接修复)或 loop(需求澄清与补全)
loop_assumption_capNo每轮假设上限(默认 3)
loop_question_budgetNo每轮最多提问数量(默认 5)
Behavior1/5

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

The description states the tool performs bug fixing (mutation), but annotations declare readOnlyHint=true. This is a direct contradiction. The description does not disclose any behavioral traits beyond the workflow steps, and the annotation conflict severely undermines transparency.

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?

Description is two sentences, front-loaded with purpose, and contains no extraneous information. Every word serves a purpose.

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

Completeness2/5

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

Despite having 13 parameters and no output schema, the description only outlines the workflow process. It fails to describe return values, side effects, or prerequisites. The annotation contradiction further reduces completeness.

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% with all parameters having descriptions. The tool description adds no additional semantic meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool is for finding problems, fixing bugs, and troubleshooting anomalies. It also describes the default workflow steps. However, it does not differentiate from the sibling tool 'fix_bug', which appears to have overlapping functionality.

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

Usage Guidelines3/5

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

Description implies when to use (bug fixing/troubleshooting) but provides no explicit when-not-to-use or alternatives. Given the presence of sibling 'fix_bug', the lack of comparative guidance could lead to confusion.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mybolide/mcp-probe-kit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server