이번 라운드에 잡은 버그를 학습 corpus에 1줄 패턴으로 증류 추가(다음 라운드에 먼저 점검). 실제로 잡은 것만.
| Name | Required | Description | Default |
|---|---|---|---|
| fix | Yes | 수정 원칙 | |
| hit | Yes | 적중 예시(프로젝트·날짜·file:line) | |
| name | Yes | 짧은 이름 | |
| tags | No | 스택 태그 쉼표(postgres,stream,curriculum 등) | |
| klass | Yes | 버그 클래스(단위/제약·끊긴고리·권한경계 등) | |
| signal | Yes | 탐지 신호 — 어떤 쿼리/grep/코드위치로 잡는가 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a write operation ('distill') and a constraint ('only actually caught'), but it does not mention authorization needs, side effects, or any destructive aspects. The behavioral impact is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences in Korean, no wasted words. It front-loads the core purpose and adds a key constraint. However, it could be slightly more structured or include an example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 6 parameters and no output schema, the description is adequate but leaves gaps. It explains the overarching goal but does not detail how the tool fits into the bug detection pipeline or what happens post-recording. The sibling context hints at a broader system, but the description alone is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already describes each parameter. The tool description does not add additional meaning beyond the schema, so the baseline of 3 is appropriate. No extra context is provided for how to fill the pattern fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to distill bugs caught in the current round into a 1-line pattern in the learning corpus for checking in the next round. The verb 'distill' and resource 'bugs into pattern' are specific, and the tool is distinguishable from siblings like spider_checklist and spider_pull_corpus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: only record bugs that were actually caught. It does not explicitly state when to prefer this tool over alternatives (e.g., spider_pull_corpus) or when not to use it, leaving the agent with insufficient context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes due to detailed descriptions, but some potential overlaps exist (e.g., baton_revoke, baton_close_room, baton_leave). The complex domain is well-differentiated overall.
The baton_ and spider_ prefixes provide consistency, but within baton_ there is a mix of verb-only, noun, and verb_noun patterns (e.g., baton_approve vs baton_account). Not fully predictable.
With 45 tools, the server is very large and may overwhelm agents. While the domain is complex, many tools could potentially be consolidated, making the count excessive.
The tool surface covers account, room, handoff, verification, cost, memory, hub, task, and spider domains thoroughly. Minor gaps exist (e.g., no explicit tool to list rooms), but core workflows are well-supported.