Skip to main content
Glama

start_bugfix

Read-only

Diagnose and fix software bugs by analyzing error messages, stack traces, and code context. Uses a structured 8-step process to identify root causes, propose fixes, and generate tests.

Instructions

当用户需要找问题、修 bug、排查异常、定位回归、分析失败原因、分析为什么没生效、先分析再修时使用。默认按 TBP 8 步法编排:取证澄清→分析定位→修复方案→生成测试。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
docs_dirNo文档目录。可选,默认 docs
stack_traceNo堆栈跟踪。可选
code_contextNo相关代码。可选
feature_nameNo关联功能规格名(对应 docs/specs/<feature_name>/)。提供后或能自动识别时,修复闭环会插入 check_spec 闸门
project_rootNo项目根目录绝对路径。建议显式传入;docs_dir 等相对路径参数应统一相对该项目根目录解析,避免依赖客户端 cwd。
analysis_modeNo分析方法。默认 tbp8(丰田问题分析 8 步法)
error_messageNo错误信息
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 describes a write operation (fixing bugs), but the annotation 'readOnlyHint' is set to true, which is a direct contradiction. No further behavioral details are provided.

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 description is concise with two sentences covering use cases and method, though it could be more structured to highlight key actions and constraints.

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?

Given 12 parameters and no output schema, the description fails to explain return values, side effects, or provide sufficient context for a complex bug-fixing workflow. The annotation contradiction further undermines 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 description coverage is 100% for all 12 parameters, so the schema already documents each parameter. The description adds no new parameter-specific information beyond mentioning the methodology.

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?

The description clearly states the tool's purpose: find problems, fix bugs, etc., and specifies the TBP 8-step methodology. However, it does not distinguish from the sibling tool 'fix_bug', which likely has 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?

The description lists conditions for use ('when the user needs to...') and mentions a default workflow, but it does not provide guidance on when NOT to use or explicitly contrast with alternatives like 'fix_bug'.

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