This server is an MCP server that turns Claude Code into a team leader and routes work to GPT/Gemini expert agents for multi-LLM collaboration, code review, research, implementation delegation, and team orchestration.
Expert consultation: Ask questions to 18+ AI experts (strategist, security, frontend, etc.) via consult_expert, run parallel consultations, or auto-route by category.
Implementation delegation: Delegate coding tasks to 1-3 GPT agents with delegate_task, with code changes only allowed by the implementer role.
Moderated debates: Run multi-round panel discussions with a moderator and auto-assigned or custom personas.
Ensemble reasoning: Combine expert opinions via parallel, synthesize, vote, best-of-n, and chain strategies.
Background execution: Start, check, cancel, and list long-running async expert jobs.
Code review and analysis: Multi-perspective code review, symbol/definition/reference lookup, AST search/replace, and repository search.
Design and research workflows: Multi-expert design sessions, topic research (quick/normal/deep), and orchestrated task execution with Ralph Loop retry.
Git operations: Atomic commits, history search, rebase planning, squash helper, and branch analysis.
Web and docs lookup: Web search, library documentation retrieval, and library search.
Memory and context management: Add/list/clear memory, inspect and configure context/truncation settings.
Hooks and reliability controls: Manage session recovery, edit recovery, comment checking, magic keywords, directory injection, and TODO enforcement.
Skill system: List, get, execute, activate, deactivate, reload, and manage skills plus skill-specific MCP servers.
MCP server management: Add, remove, start, stop, restart, list, and inspect configured MCP servers.
Interactive terminal: Create, send, read, list, and kill tmux-based interactive bash sessions.
Command/agent discovery: List and run agents and slash commands, search commands, and manage command sources.
Health and diagnostics: Check router health, clear caches, and clean up background tasks.
Provides Git integration tools for atomic commits, history search, rebase planning, and branch analysis.
Integrates with Google Gemini via the gemini CLI tool, enabling AI agents to perform code review, analysis, and debate moderation using Gemini models.
Integrates with OpenAI's API via the codex CLI tool, enabling AI agents to perform code changes, design, and analysis tasks using GPT models.
Provides security analysis using OWASP standards through a dedicated expert role and automated security audit skills.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@llm-router-mcp delegate to GPT to implement user authentication"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Claude Code를 팀 리더로, GPT/Gemini를 전문가 팀으로 활용하는 MCP 서버
LLM Router MCP는 Claude Code가 팀 리더 역할을 하며, GPT/Gemini 전문가에게 업무를 위임하는 MCP 서버입니다.
Note: Claude 모델은 MCP를 통해 호출되지 않습니다. Claude Code가 직접 Claude 역할을 수행하므로, 중첩 세션 문제를 피하면서 진정한 다중 LLM 협업이 가능합니다.
항목 | 수량 |
MCP 도구 | 109개 |
내장 훅 | 38개 |
AI 전문가 | 18개 |
내장 스킬 | 15개 |
멀티 LLM 협업: Claude Code(리더) + GPT/Gemini 전문가 협업
역할 분담: implementer(codex)만 코드 변경 가능, 나머지 17명은 read-only로 강제
자동 폴백: Rate limit 발생 시 자동으로 다른 전문가로 전환
병렬 위임: delegate_task로 GPT 에이전트 1~3명에게 구현 작업 병렬 위임
중재형 토론: 중재자가 2라운드 패널 토론을 진행하고 최종 요약 반환
백그라운드 실행: 장시간 작업을 백그라운드에서 비동기 실행
HUD Statusline: 실시간 비용, 컨텍스트, 전문가 활동 모니터링
Related MCP server: Gemini Collaboration MCP Server
다른 프로젝트에서 AI에게 아래처럼 요청하면 글로벌 CLI 설치와 Claude Code MCP 등록까지 진행하도록 유도할 수 있습니다.
예시 프롬프트:
LLM Router MCP를 npm 글로벌 설치 방식으로 설치하고 Claude Code에 등록해줘.
프로젝트 CLAUDE.md는 300줄 이내로 유지해야 하니, 공용 사용법 문서는 별도 참조 문서로 연결해줘.AI가 수행해야 하는 적용 작업:
npm install -g llm-router-mcp 실행
custommcp install로 Claude Code MCP 설정 자동 등록
custommcp doctor로 Node.js, MCP 등록, codex, gemini CLI 상태 확인
대상 프로젝트의 CLAUDE.md에 공용 템플릿 구조 반영
프로젝트 CLAUDE.md에는 플러그인 사용 시 plugin/docs/USAGE.md를 읽으라고 적고, 프로젝트 고유 규칙만 유지
설치 후 llm_router_health 등으로 연결 확인
npm install -g llm-router-mcp
custommcp install
custommcp doctorcustommcp install은 ~/.claude/settings.json을 백업한 뒤 llm-router-mcp MCP 서버를 자동 등록합니다. 기존 llm-router-mcp 등록이 있으면 현재 설치 경로로 교체합니다.
전역 설치 단계에서는 레거시 CLIProxy 설정 스크립트를 자동 실행하지 않습니다. Claude Code 등록과 검증은 custommcp install과 custommcp doctor가 담당합니다.
터미널에서 사용할 LLM CLI 도구가 인증된 상태여야 합니다:
codex — OpenAI Codex CLI (GPT 전문가 11명). codex login으로 인증
agy — Antigravity CLI (Gemini 전문가 7명). 최초 실행 시 브라우저 인증
Gemini CLI(
@google/gemini-cli)는 2026-06-18 공식 종료되어 더 이상 쓰지 않습니다. Google 계열은 후속작인 Antigravity CLI(agy)로 전환됐습니다.
claude CLI는 선택입니다. consult_expert에 model: "opus"를 명시할 때만
쓰이며, 사용자 본인의 Claude 구독 한도를 소모합니다. 설치돼 있지 않아도
나머지 기능은 정상 동작합니다.
설치 확인:
npm run probe # 세 CLI 전부에 실제로 물어봐서 검증EXA_API_KEY=your_exa_api_key # 선택: 웹 검색
CONTEXT7_API_KEY=your_key # 선택: 라이브러리 문서
CLI_CODEX_PATH=codex # 선택: PATH에 없을 때만 지정
CLI_AGY_PATH=agy # 선택: PATH에 없을 때만 지정
CLI_CLAUDE_PATH=claude # 선택: opt-in 전용
CLAUDE_MAX_BUDGET_USD=1.0 # 선택: claude -p 호출당 비용 상한custommcp install이 Claude Code 설정을 자동으로 등록합니다. 프로젝트별 사용 규칙을 빠르게 붙이고 싶으면 공용 템플릿 plugin/templates/CLAUDE.md를 프로젝트 루트 CLAUDE.md의 시작점으로 사용하고, 플러그인 상세 운영 규칙은 plugin/docs/USAGE.md를 참조하면 됩니다.
저장소와 npm 패키지 이름은 llm-router-mcp입니다. 로컬 개발 폴더도 llm-router-mcp/를 권장합니다. CLI 명령어 custommcp는 기존 사용자 호환성을 위해 유지합니다.
CLI 도구 | Sandbox | 코드 변경 | 용도 | 자동 로드 |
|
|
| 설계·리뷰·구현 |
|
|
| 불가 | 리뷰/분석 전용 | — |
|
| 불가 | opt-in 3자 검증 | — |
전문가 18명 중 implementer 하나만 쓰기 권한을 갖습니다. 나머지 17명은
CLI 레벨에서 read-only가 강제되므로, 프롬프트로 지시해도 파일을 고칠 수 없습니다.
쓰기가 필요하면 delegate_task를 쓰세요.
모든 CLI 도구가 파일 경로를 넘기면 직접 읽음 (토큰 절약)
2명 이상 전문가 호출 시 반드시 병렬 (consult_experts_parallel)
GPT/Gemini 전문가만 MCP를 통해 호출됩니다. Claude 관련 분석/판단은 Claude Code가 직접 수행합니다.
전문가 | 모델 | 역할 | 폴백 |
| GPT | 아키텍처 설계, 디버깅 전략 | codereview → momus |
| Gemini Pro + GPT | 통합 코드 리뷰 (perspectives로 GPT+Gemini 병렬 리뷰) | strategist → momus |
| Gemini Pro | UI/UX, 컴포넌트 설계 | strategist → momus |
| GPT | 전략적 계획, 문제 분해 | strategist → codereview |
| Gemini Pro | 비판적 분석, 품질 평가 | codereview → strategist |
전문가 | 모델 | 역할 | 폴백 |
| GPT | OWASP/CWE 보안 분석 | codereview → strategist |
| GPT | TDD/테스트 전략 | codereview → strategist |
| GPT | DB 설계, 쿼리 최적화 | strategist → codereview |
| GPT | CI/CD, Docker, K8s | strategist → codereview |
| Gemini Pro | 현실 검증, dead code 탐지 | momus → codereview |
| GPT | 심볼/참조 분석 | codereview → strategist |
| GPT | GPT 코드리뷰 - SOLID/설계/실무 관점 (READ-ONLY) | codereview → momus |
토론 시 AI가 자동으로 역할을 부여하는 빈 슬롯 (GPT/Gemini only):
전문가 | 모델 |
| GPT |
| GPT |
| Gemini Pro |
| Gemini Flash |
전문가 | 모델 | 역할 |
| Gemini Pro | 패널 토론 중재 및 최종 요약 |
도구 | 설명 |
| 전문가에게 직접 질문 |
| 2명 이상 전문가 병렬 상담 |
| 카테고리 기반 자동 라우팅 |
| 여러 전문가 의견 종합 |
| 중재자가 2라운드 패널 토론 진행 |
도구 | 설명 |
| GPT 에이전트 1~3명에게 구현 작업 병렬 위임 (plan → execute → report) |
| 멀티 관점 코드 리뷰 (files 경로 기반, context_docs, 1~3 perspectives 병렬) |
도구 | 설명 |
| 비동기 전문가 실행 시작 |
| 작업 결과 확인 |
| 실행 중인 작업 취소 |
| 전체 백그라운드 작업 목록 |
도구 | 설명 |
| 다중 전문가 설계 워크플로우 |
| 주제 연구 (quick/normal/deep) |
도구 | 설명 |
| 심볼 정의 위치 |
| 심볼 참조 찾기 |
| 타입/문서 정보 |
| AST 패턴 검색 |
| AST 패턴 치환 |
도구 | 설명 |
| 자동 그룹화 커밋 |
| 커밋 히스토리 검색 |
| 리베이스 계획 |
| 브랜치 분석 |
도구 | 설명 |
| Exa 웹 검색 |
| 라이브러리 문서 조회 |
| 웹 페이지 캡처 |
| 세션 히스토리 검색 |
38개 내장 훅으로 동작 확장:
훅 | 설명 |
| 작업 완료 강제 오케스트레이션 |
| TODO 완료 강제 |
| 확장 사고 모드 |
|
|
| 매직 키워드 감지 |
훅 | 설명 |
| 세션 에러 자동 복구 |
| 편집 에러 복구 |
| 선제적 컨텍스트 압축 |
| 컨텍스트 사용량 모니터링 |
| 반복 패턴 감지 |
| Rate limit 자동 처리 |
훅 | 설명 |
| 버전 업데이트 알림 |
| 작업 완료 알림 |
| HUD 상태 업데이트 |
| AGENTS.md/GEMINI.md 자동 로드 |
15개 내장 스킬이 자연어 요청을 인식하여 자동으로 호출됩니다:
스킬 | 설명 | 호출 방식 |
| Claude 설계 후 Agent 자체 검토 + GPT 설계 검토를 거쳐 GPT 전체 구현 위임 | 자동 |
| Claude와 GPT가 설계 검토를 거친 뒤 역할을 나눠 동시 작업 | 자동 |
| 9단계 코드 리뷰 파이프라인 | 자동 |
| 코드 검증 (빌드/타입/참조) | 자동 |
| OWASP 보안 감사 | 자동 |
| 기술 리서치 | 자동 |
| 설계 워크플로우 | 자동 (확인 후) |
| TDD 워크플로우 | 자동 (확인 후) |
| 백그라운드 작업 | 자동 (확인 후) |
| 중재형 토론 | 자동 (확인 후) |
| 전문가 상담 | 자동 |
| 교차 검증 | 자동 |
| 깊은 분석 | 자동 |
| 헬스체크 | 자동 |
| 시스템 가이드 | 자동 참조 |
중재자가 안건을 모든 참여자에게 병렬로 던지고, 1차 응답을 종합한 뒤 다시 한 번 병렬 재질의합니다.
moderated_debate({
agenda: "마이크로서비스 vs 모놀리식",
participant_count: 3,
repeat_count: 1
})직접 페르소나를 주고 싶으면 participants를 넘기고, 아니면 participant_count(2-4)만 넘겨 자동 페르소나 배정을 사용합니다.
llm-plan과 llm-planAll은 바로 구현에 들어가지 않고, 설계 검토 게이트를 먼저 통과합니다.
llm-plan흐름:
Claude가 plan 모드에서 설계와 GPT 서브태스크를 작성
Claude가 Agent 도구로 설계 검토를 수행
GPT 설계 전문가가 2차 검토
두 검토를 통과하면 사용자 확인 후 GPT 에이전트 1~3명에게 구현 위임
구현 결과를 멀티 관점으로 리뷰
특징:
Claude는 설계와 리뷰만 수행
실제 코드 변경은 GPT만 수행
설계 검토 중 이슈가 나오면 plan으로 돌아가 수정 후 재검토
llm-planAll흐름:
Claude가 plan 모드에서 자신의 작업과 GPT 작업을 분리해 설계
Claude가 Agent 도구로 설계 검토를 수행
GPT 설계 전문가가 2차 검토
두 검토를 통과하면 사용자 확인
GPT 작업을 먼저 백그라운드 위임하고, Claude도 자기 파일 범위에서 동시 구현
전체 결과를 통합 리뷰
특징:
Claude와 GPT가 같은 파일을 수정하면 안 됨
Claude 작업과 GPT 작업은 독립적이어야 함
설계 검토 전에는 위임이나 구현을 시작하지 않음
복잡한 문제에 대한 깊은 분석:
키워드 | 레벨 | 토큰 예산 |
| normal | 10,000 |
| deep | 20,000 |
| extreme | 50,000 |
모델 | 타임아웃 | 이유 |
| 20분 |
|
Gemini 3.1 Pro (High) | 15분 | agy 자율 실행 |
Gemini 3.5/3.6 Flash | 5분 | agy 자율 실행 |
기타 | 1분 | 기본값 |
llm-router-mcp/
├── src/
│ ├── index.ts # MCP 서버 진입점
│ ├── experts/ # 전문가 정의 (11개 + 토론 전용 슬롯)
│ ├── tools/ # MCP 도구 (109개)
│ ├── hooks/builtin/ # 내장 훅 (38개)
│ ├── hud/ # HUD 상태 관리
│ ├── features/ # 기능 모듈
│ │ ├── skill-system/ # 스킬 시스템
│ │ ├── mcp-loader/ # MCP 서버 관리
│ │ └── boulder-state/ # 볼더 상태 관리
│ ├── services/ # 핵심 서비스
│ │ ├── expert-router.ts # 전문가 라우팅
│ │ ├── cliproxy-client.ts # CLI 도구 오케스트레이터
│ │ ├── providers/ # CLI 프로바이더 (Gemini/Codex only)
│ │ └── background-manager.ts # 백그라운드 작업 관리
│ └── utils/ # 유틸리티
├── plugin/skills/ # 내장 스킬 (15개)
└── dist/ # 빌드 출력터미널에 설치된 CLI 도구를 child_process.spawn()으로 직접 호출합니다.
agy — Gemini 3.1 Pro / 3.6 Flash 등 (리뷰/분석 전용)
codex — GPT 계열 모델 (implementer만 코드 변경 가능)
Note:
claudeCLI는 사용하지 않습니다. Claude Code가 직접 Claude 역할을 수행합니다.
각 CLI 도구가 터미널에서 인증 완료된 상태여야 합니다.
CLI 도구 경로는 .env에서 설정 가능합니다 (PATH에 있으면 생략 가능):
CLI_AGY_PATH=agy
CLI_CODEX_PATH=codex# CLI 도구 설치 확인
gemini --version
codex --version
# 인증 상태 확인
gemini auth status
codex auth status시스템이 자동으로:
HTTP 429 및 에러 메시지 패턴 감지
모델을 제한 상태로 표시
폴백 전문가로 라우팅
지수 백오프로 재시도
MIT
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | 취소할 작업 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | 필터링할 상태 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | 조회할 작업 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| expert | Yes | 실행할 전문가 | |
| prompt | Yes | 작업 내용 | |
| context | No | 추가 컨텍스트 | |
| task_id | No | 커스텀 작업 ID (미지정 시 자동 생성) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| add_dir | No | 스캔할 디렉토리 추가 | |
| enabled | No | 명령어 디스커버리 활성화/비활성화 | |
| remove_dir | No | 디렉토리 제거 | |
| add_dir_type | No | 추가할 디렉토리 타입 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 실행할 명령어 이름 또는 별칭 | |
| params | No | 명령어 파라미터 (키-값 쌍) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 명령어 이름 또는 별칭 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | 태그로 필터링 | |
| source | No | 소스 필터: all(전체), project(프로젝트), claude(.claude), global(전역) | all |
| include_invalid | No | 유효하지 않은 명령어도 포함 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | 스캔 기준 디렉토리 (기본: 현재 작업 디렉토리) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 실행할 액션: status(상태 조회), reset(초기화), config(설정 변경) | |
| enabled | No | 주석 검사 활성화 여부 (config 액션용) | |
| min_severity | No | 최소 보고 심각도 1-3 (config 액션용) | |
| check_ai_patterns | No | AI 생성 패턴 검사 여부 (config 액션용) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| expert | Yes | 자문할 전문가 | |
| context | No | 관련 코드, 설계 문서 등 추가 컨텍스트 | |
| persona | No | blank 전문가 사용 시 페르소나 설명 (예: '투자 전문가', '마케팅 전략가'). blank 전문가에게는 필수. | |
| question | Yes | 전문가에게 할 질문 | |
| use_tools | No | 전문가가 웹 검색, 문서 조회 등 도구를 사용할 수 있게 함 (기본: true) | |
| image_path | No | 분석할 이미지 파일 경로 또는 URL (multimodal 전문가용). 로컬: ./uploads/, ./images/ 내 파일만 허용. URL: HTTPS만 허용. | |
| skip_cache | No | 캐시 무시하고 새로 호출 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | 모든 전문가에게 공유할 컨텍스트 | |
| experts | Yes | 동시에 호출할 전문가 목록 | |
| skip_cache | No | 캐시 무시하고 새로 호출 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| inject_warnings | No | 경고 메시지 주입 여부 | |
| warning_threshold | No | 경고 임계값 (0.1-0.95, 기본: 0.7) | |
| critical_threshold | No | 위험 임계값 (0.5-0.99, 기본: 0.9) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| reset | No | 컨텍스트 상태 초기화 여부 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | 전체 작업 설명 | |
| files | No | 작업 대상 파일 경로 (codex가 직접 읽음, 상대경로만) | |
| context | No | 추가 컨텍스트 (계획 발췌, 요구사항 등) | |
| agent_tasks | No | 에이전트별 서브태스크 설명 (parallel_agents > 1일 때 필수) | |
| context_docs | No | 필수 읽기 문서 경로 (CLAUDE.md, AGENTS.md 등 - codex가 직접 읽음, 상대경로만) | |
| parallel_agents | No | 병렬 GPT 에이전트 수 (1~3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | 설계 주제 (예: '트레이딩 알고리즘', '인증 시스템') | |
| parallel | No | 설계와 조사를 병렬로 실행 (기본: true) | |
| constraints | No | 제약조건 (기술 스택, 성능 요구 등) | |
| skip_review | No | 리뷰 단계 건너뛰기 (기본: false) | |
| requirements | No | 요구사항 목록 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 실행할 액션: status(상태 조회), reset(통계 초기화), clear_cache(캐시 삭제), config(설정 변경) | |
| enable_rules | No | .claude/rules/ 주입 활성화 (config 액션용) | |
| enable_agents | No | AGENTS.md 주입 활성화 (config 액션용) | |
| enable_readme | No | README.md 주입 활성화 (config 액션용) | |
| cache_ttl_minutes | No | 캐시 TTL (분, config 액션용) | |
| max_content_length | No | 파일당 최대 콘텐츠 길이 (config 액션용) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 실행할 액션: status(상태 조회), reset(초기화), config(설정 변경) | |
| enable_fuzzy_match | No | 퍼지 매칭 제안 활성화 여부 (config 액션용) | |
| enable_suggestions | No | 복구 제안 활성화 여부 (config 액션용) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 앙상블로 실행할 쿼리 | |
| preset | Yes | 프리셋 ID | |
| context | No | 추가 컨텍스트 | |
| vote_options | No | 투표 선택지 (vote 프리셋용) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | 실행 횟수 (best_of_n 전략용) | |
| query | Yes | 앙상블로 실행할 쿼리 | |
| context | No | 추가 컨텍스트 | |
| experts | No | 참여할 전문가 목록 | |
| strategy | No | 앙상블 전략 | parallel |
| skip_cache | No | 캐시 사용 안 함 | |
| synthesizer | No | 합성 담당 전문가 (synthesize 전략용) | |
| vote_options | No | 투표 선택지 (vote 전략에서 필수) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | 특정 주제 검색 (예: 'hooks', 'routing', 'state management') | |
| topic | No | 문서 섹션 필터 (예: 'api', 'guide', 'tutorial') | |
| library | Yes | 라이브러리/프레임워크 이름 (예: 'react', 'nextjs', 'tailwindcss') | |
| max_tokens | No | 최대 토큰 수 (기본: 5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Git 저장소 경로 (기본: 현재 디렉토리) | |
| group_by | No | 변경사항 그룹화 기준: file_type(확장자), directory(디렉토리), semantic(의미적 그룹) | semantic |
| analyze_only | No | true면 분석만, false면 실제 커밋 수행 (기본: true) | |
| include_staged | No | 스테이징된 변경사항 포함 (기본: true) | |
| include_unstaged | No | 스테이징되지 않은 변경사항 포함 (기본: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Git 저장소 경로 (기본: 현재 디렉토리) | |
| show_stale | No | 오래된(병합됨) 브랜치 표시 | |
| compare_with | No | 비교할 브랜치 (기본: main 또는 master) | |
| include_remote | No | 원격 브랜치 포함 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Git 저장소 경로 (기본: 현재 디렉토리) | |
| query | No | 검색할 텍스트 (커밋 메시지, diff 내용) | |
| since | No | 시작 날짜 (예: '2024-01-01', '1 week ago') | |
| until | No | 종료 날짜 (예: '2024-12-31', 'yesterday') | |
| author | No | 작성자 필터 (이름 또는 이메일) | |
| branch | No | 특정 브랜치에서 검색 (기본: 현재 브랜치) | |
| file_path | No | 특정 파일/경로 히스토리만 검색 | |
| max_count | No | 최대 결과 수 (기본: 20, 최대: 100) | |
| search_in_diff | No | diff 내용에서도 검색 (git log -S) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | 리베이스 기준 브랜치 또는 커밋 (예: 'main', 'HEAD~5') | |
| path | No | Git 저장소 경로 (기본: 현재 디렉토리) | |
| action | No | plan: 리베이스 계획 생성, preview: 충돌 예측, execute: 실제 리베이스 (주의!) | plan |
| interactive | No | 인터랙티브 리베이스 계획 생성 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Git 저장소 경로 (기본: 현재 디렉토리) | |
| commits | Yes | 스쿼시할 커밋 수 (최근 N개) | |
| message | No | 새 커밋 메시지 (미지정 시 자동 생성) | |
| preview_only | No | true면 미리보기만, false면 실제 스쿼시 (기본: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | 파일 경로 필터 (예: src/, *.config.js) | |
| query | Yes | 검색 쿼리 (코드 패턴, 함수명, 클래스명 등) | |
| regex | No | 정규식 사용 (기본: false) | |
| language | No | 프로그래밍 언어 필터 (예: TypeScript, Python, Go) | |
| repository | No | 특정 레포지토리 필터 (예: facebook/react) | |
| whole_word | No | 전체 단어 매칭 (기본: false) | |
| max_results | No | 최대 결과 수 (기본: 25, 최대: 100) | |
| case_sensitive | No | 대소문자 구분 (기본: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
대화형 bash 세션 생성 (tmux 기반)
| Name | Required | Description | Default |
|---|---|---|---|
| shell | No | 사용할 셸 (기본: bash 또는 시스템 기본) | |
| working_dir | No | 작업 디렉토리 (기본: 현재 디렉토리) | |
| session_name | No | 세션 이름 (기본: omo-{timestamp}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It discloses that the session is tmux-based, which is a useful behavioral detail, but it does not mention side effects, persistence, cleanup, or how the session is identified or referenced afterward. This leaves significant behavioral ambiguity for a mutating operation.
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 a single, short sentence that is front-loaded and contains zero filler. It efficiently conveys the core purpose and a key implementation detail (tmux-based) without wasting words.
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?
For a simple create operation, the description is moderately complete, but it does not explain what happens after creation (e.g., how to connect via sibling tools, whether a session ID is returned, or how the tmux session is named). With no output schema, some of this context falls on the description, which omits it. Sibling tools provide context but the description itself lacks these details.
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%, with all three parameters (shell, working_dir, session_name) described in the input schema. The description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate because the schema handles parameter documentation fully.
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 '대화형 bash 세션 생성 (tmux 기반)' clearly states a specific action (create) on a specific resource (interactive bash session) and notes the tmux basis. It distinguishes this tool from its siblings (interactive_bash_send, interactive_bash_read, interactive_bash_list, interactive_bash_kill) by explicitly indicating creation rather than interaction or management.
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?
Usage context is implied: one would use this to create a session before using send/read/kill. However, the description does not explicitly state when to use or not use this tool, nor does it mention alternatives or prerequisites. The sibling tool names suggest a lifecycle, but the description itself provides no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
대화형 세션 종료
| Name | Required | Description | Default |
|---|---|---|---|
| session_name | Yes | 종료할 세션 이름 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says '대화형 세션 종료' (end interactive session) but does not explain what happens to the session process, whether termination is graceful, if it is idempotent, or any side effects like losing unsaved state.
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 a single, concise sentence with no redundant words. It is front-loaded and easy to scan, though its brevity borders on under-specification for a destructive operation.
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 that this is a kill operation with no annotations, no output schema, and only a one-sentence description, the context is critically incomplete. The agent lacks information about the consequences of killing the session, whether the session name must be obtained beforehand, or any recovery options.
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?
The schema covers 100% of the single parameter (session_name) with a description '종료할 세션 이름' (session name to terminate). The tool description adds no extra meaning beyond what the schema already provides, so a baseline of 3 is appropriate.
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 indicates the action (terminate) and the resource (interactive session), and it is distinct from sibling tools like interactive_bash_create, interactive_bash_send, and interactive_bash_read. However, it lacks any explicit scope or nuance, such as specifying that it targets a named bash session, which would make it fully unambiguous.
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?
There is no guidance on when to use this tool versus alternatives like interactive_bash_create or ralph_loop_cancel. The description simply states the action without providing context on prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
활성 대화형 세션 목록
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | 세션 이름 필터 (정규식) |
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 only mentions 'active sessions' but does not explicitly state that the operation is read-only, what the output structure is (since there is no output schema), or any side effects. This minimal description leaves the agent to infer basic safety from the name.
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 a single short phrase, which is appropriately concise and front-loaded. It contains no filler words, though it could be slightly more descriptive without losing efficiency. For a simple list tool, this is well-sized.
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?
With no output schema and a description that is just 'List of active interactive sessions', the return value and usage context are underspecified. An agent invoking this tool would not know what data to expect (IDs, names, status) or how to use the result. The schema helps with the filter, but the description lacks sufficient context for full invocation.
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?
The input schema fully describes the single 'filter' parameter as a regex for session names (100% coverage), so the baseline is 3. The tool description adds no additional parameter semantics, but the schema already provides sufficient documentation.
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 '활동 중인 대화형 세션 목록' translates to 'List of active interactive sessions', clearly stating the action (list) and resource (active interactive sessions). It distinguishes itself from sibling tools like interactive_bash_create, interactive_bash_send, and interactive_bash_kill by focusing on listing, and adds the scope of 'active' sessions.
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 no guidance on when to use this tool versus alternatives. It doesn't mention typical use cases (e.g., checking running sessions before sending input) or contrast with other listing or management tools. The filter parameter is present in the schema but not mentioned in the description, leaving the agent without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
대화형 세션 출력 읽기
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | 읽을 라인 수 (기본: 100) | |
| session_name | Yes | 대상 세션 이름 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'read' output, implying a non-destructive operation, but does not disclose whether it consumes output, blocks, errors on missing sessions, or any other behavioral traits. This is a significant gap for a tool interacting with sessions.
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 a single short phrase, making it very concise, but it lacks structural formatting (e.g., no full sentences). While not verbose, it is under-specified and does not provide a complete picture, earning a middle score.
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?
With no annotations and no output schema, the description should provide more context about return format, session requirements, and relationship to sibling tools. It does not explain what the user will receive (output lines) or how to interpret results. The schema covers parameters but not behavior, leaving the tool incomplete for reliable selection and invocation.
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% for both parameters (lines and session_name), so the description adds nothing beyond what the schema already provides. The baseline of 3 is appropriate; the tool description does not enhance parameter understanding.
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 states the tool reads output from an interactive session, a clear verb+resource combination. While it doesn't explicitly differentiate from siblings like interactive_bash_list, the verb 'read' strongly implies retrieving output, distinguishing it from create/send/kill. It is specific enough for basic purpose understanding.
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?
No guidance is provided on when to use this tool versus alternatives, such as interactive_bash_list or interactive_bash_send. There is no mention of prerequisites (e.g., existing session) or exclusions. The user must infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
대화형 세션에 명령어 전송
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | 실행할 명령어 | |
| timeout_ms | No | 타임아웃 밀리초 (기본: 30000) | |
| session_name | Yes | 대상 세션 이름 | |
| wait_for_output | No | 출력 대기 여부 (기본: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. However, it only states the basic action without mentioning whether it waits for output, how timeouts work, what happens if the session doesn't exist, or any side effects. The parameters (wait_for_output, timeout_ms) hint at behavior, but the description itself adds no behavioral context.
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 a single, focused sentence with zero superfluous content. It is front-loaded and easily scannable, making it appropriate in size for the tool's purpose.
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?
The tool has 4 parameters, no output schema, and no annotations, yet the description omits critical contextual details like return values, behavior when the session is not found, and how wait_for_output and timeout_ms affect execution. This level of description is insufficient for an agent to confidently use the tool in varied scenarios.
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%, so the schema already documents all four parameters adequately. The description adds no additional meaning beyond restating the purpose; it doesn't clarify parameter relationships, edge cases, or expected input formats. Since the schema handles parameter semantics, a baseline score of 3 is appropriate.
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 '대화형 세션에 명령어 전송' (Send command to interactive session) uses a specific verb and resource, clearly distinguishing it from sibling tools like interactive_bash_create, interactive_bash_read, interactive_bash_list, and interactive_bash_kill.
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 implies the tool is used to send commands to an existing interactive session, but it does not explicitly state when to use it versus alternatives, such as first creating a session with interactive_bash_create or reading output with interactive_bash_read. No exclusions or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| reload | No | Force reload agents from disk |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| reload | No | Force reload commands from disk | |
| namespace | No | Filter by namespace (e.g., "git") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| clear_cache | No | 캐시 초기화 | |
| cleanup_tasks | No | 오래된 백그라운드 작업 정리 | |
| include_details | No | 상세 정보 포함 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 실행할 액션: status(상태 조회), reset(통계 초기화), clear(활성 키워드 초기화), config(설정 변경), list(키워드 목록) | |
| enabled | No | 매직 키워드 활성화 여부 (config 액션용) | |
| enable_keyword | No | 특정 키워드 활성화 (config 액션용) | |
| inject_context | No | 컨텍스트 주입 여부 (config 액션용) | |
| disable_keyword | No | 특정 키워드 비활성화 (config 액션용) | |
| show_activation | No | 활성화 메시지 표시 여부 (config 액션용) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an MCP server configuration at runtime
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory | |
| env | No | Environment variables | |
| args | No | Command arguments | |
| name | Yes | Server name | |
| scope | No | Server scope | project |
| command | Yes | Server command | |
| auto_start | No | Start server after adding |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden of disclosing side effects. It only states the action without indicating whether existing configurations are overwritten, whether the server is started, or how scope affects persistence. This is a significant transparency gap for a mutation tool.
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 a single sentence that directly conveys the tool's purpose with no filler. It is appropriately sized and front-loaded, earning a high score for conciseness.
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?
With 7 parameters, a nested env object, and no annotations or output schema, this tool has moderate complexity. The one-line description does not explain the tool's return value, the meaning of 'runtime' for configuration persistence, or how scope and auto_start interact. It is far from complete for safe and correct usage.
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?
The input schema provides descriptions for all 7 parameters (100% coverage), so the baseline is 3. The tool description adds no additional parameter-level semantics, but the schema already handles documentation adequately.
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 verb ('Add'), the resource ('MCP server configuration'), and the context ('at runtime'). It effectively distinguishes from sibling tools like mcp_servers_list, mcp_servers_start, and mcp_servers_remove, which perform different operations on server configurations.
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 phrase 'at runtime' implies that this tool is for dynamically adding configurations, but the description provides no explicit guidance on when to use it versus alternatives. It does not mention exclusions or suggest sibling tools for related operations such as removing or starting servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about an MCP server
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Server name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get detailed information'. It does not state whether this is a read-only operation, what happens if the server name is invalid, whether any side effects occur, or what 'detailed information' includes. This is a minimal disclosure that fails to convey the tool's behavioral traits.
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 a single, front-loaded sentence with no wasted words. It achieves the bare minimum for clarity, though it could be slightly more informative without losing conciseness. For a simple tool with one parameter, this is appropriately sized.
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 tool's simplicity (1 parameter, no output schema), the description is too sparse. It does not explain what fields or format the 'detailed information' will be returned in, nor does it hint at error behavior or relationships to sibling list/start/stop tools. The description leaves significant gaps that are not filled by schema or annotations.
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%, as the single parameter 'name' has the description 'Server name'. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies. No extra parameter nuances are explained.
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 action ('Get') and specific resource ('detailed information about an MCP server'), using a specific verb and resource. It distinguishes from sibling tools like mcp_servers_list (which lists servers) and start/stop (which control servers), making its purpose unambiguous.
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?
No guidance is provided about when to use this tool versus alternatives. It does not mention that this is for a single, specific server as opposed to listing all servers, nor does it state any prerequisites or exclusions. The description simply states what it does without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured MCP servers
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Filter by server scope | all |
| running_only | No | Show only running servers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the transparency burden. 'List' implies a read-only, non-destructive operation, but the description does not disclose any details about output content, permissions, or rate limits.
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 a single, front-loaded sentence with no wasted words.
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?
The tool is simple with only two optional parameters and no output schema. The description sufficiently conveys the core purpose, though it could briefly mention the return format, but the low complexity makes this adequate.
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?
The schema already provides 100% coverage with clear descriptions for both 'scope' and 'running_only,' so the description adds no additional parameter meaning beyond what's in the schema.
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 uses the specific verb 'List' with a clear resource, 'configured MCP servers.' This clearly distinguishes it from sibling tools that get, start, stop, or mutate MCP servers.
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 usage is implied by the imperative 'List all configured MCP servers,' but the description does not explicitly provide when-to-use guidance or contrast with alternatives such as mcp_servers_get or mcp_servers_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload all MCP server configurations from disk
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states that it reloads configurations from disk, but does not disclose potential side effects such as whether running servers are restarted, whether existing connections are dropped, or whether invalid configuration could cause disruptions. This lack of detail is a significant gap for a tool that affects all MCP servers.
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 a single, concise sentence that is front-loaded with the core purpose. There is no wasted wording, making it an ideal size for a tool with no parameters.
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 tool's simplicity (no params, no output schema), the description provides the essential purpose. However, it lacks any context about the tool's relationship to sibling tools (e.g., when to prefer reload over restart), and it doesn't address failure modes or what happens after reloading. This is adequate but incomplete for an agent that needs to decide among similar MCP management tools.
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?
The tool has zero parameters, so the schema already provides complete coverage. Per the rubric, a baseline of 4 is appropriate for a no-parameter tool, and the description does not need to add parameter-related information.
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 action (reload), the resource (all MCP server configurations), and the source (from disk). It distinguishes itself from sibling tools like mcp_servers_restart or mcp_servers_start by specifying a configuration reload rather than a service restart.
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?
No explicit guidance is given on when to use this tool versus alternatives such as mcp_servers_restart or skill_mcp_reload. There is no mention of scenarios like 'after editing config files' or exclusions (e.g., 'use restart if you need to fully restart servers'). The intended use is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an MCP server configuration
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Server name to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only states the action 'Remove' without explaining consequences such as irreversibility, whether the server process is stopped, or whether the configuration file is permanently deleted. This is a significant gap for a destructive operation.
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 a single, concise sentence that directly states the action. There is no redundancy or unnecessary detail, making it highly efficient.
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 lack of annotations and output schema, the description carries the responsibility for explaining the tool's context. It fails to specify side effects, prerequisites, or what happens after removal, leaving the agent with incomplete information for a destructive operation.
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?
The schema provides 100% coverage for the single parameter 'name' with clear description 'Server name to remove'. The tool description adds no extra meaning beyond that, so the baseline of 3 applies.
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: remove an MCP server configuration. The specific verb 'Remove' and the resource 'MCP server configuration' make the action unambiguous and distinguish it from sibling tools like mcp_servers_add, mcp_servers_stop, and mcp_servers_restart.
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 no guidance on when to use this tool versus alternatives. It does not mention that removal is permanent or that stopping a server should be done with mcp_servers_stop, leaving the agent without context for choosing the correct operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart an MCP server
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Server name to restart |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the operation, not side effects like connection interruption, state reset, or configuration reapplication. The agent cannot anticipate consequences of calling this tool.
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 a single short sentence, front-loaded with the verb, with no wasted words. It is less complete than ideal, but for a one-parameter tool this brevity is acceptable; however, it could have included usage context without becoming wordy.
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 simplicity (one parameter, no output schema) and the presence of many sibling MCP server tools, the description should at least mention when restart is appropriate or what happens during a restart. It only states the action, leaving the agent without enough context to decide or anticipate outcome.
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 coverage is 100% (one parameter, 'name', with a description). The tool description adds no extra meaning beyond the schema; it merely restates the operation. This matches the baseline of 3 when the schema already documents the parameter.
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 'Restart an MCP server' uses a specific verb (restart) and a clear resource (MCP server), making the core purpose clear. It is distinct from sibling tools like start/stop, but it does not explicitly differentiate restart from reload, so it falls short of a perfect 5.
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 gives no guidance on when to use restart versus alternatives such as mcp_servers_reload or mcp_servers_start. There is no mention of prerequisites, effects, or situations where a restart is preferred, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an MCP server
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Server name to start |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for behavioral disclosure. 'Start an MCP server' implies a state change but does not explain side effects, idempotency, prerequisites (e.g., server must be configured), or what happens if the server is already running.
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 a single, efficiently worded sentence that immediately conveys the tool's purpose. No filler or redundant information is present.
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?
For a simple one-parameter start tool, the description is minimally viable but lacks important context such as where the server name comes from (e.g., from mcp_servers_list), whether the operation is idempotent, or what the return value looks like. Given the tool's simplicity, this is a moderate gap.
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?
The parameter schema already provides 100% coverage with 'Server name to start' for the 'name' parameter. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 'Start an MCP server' clearly identifies the verb (start) and resource (MCP server), distinguishing it from sibling tools like stop, restart, and list. However, it does not explicitly differentiate usage from closely related tools such as skill_mcp_start or mcp_servers_restart.
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?
No guidance is provided on when to use this tool versus alternatives like mcp_servers_start, mcp_servers_restart, or skill_mcp_start. The description only states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get MCP server loader statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The word 'Get' implies a read-only operation, but no details are given about what statistics are included, whether it could have side effects, or what the response format looks like. This is minimal disclosure.
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 a single clear sentence with no filler. It is appropriately sized for a tool with no parameters, and the key verb and object are front-loaded.
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?
The tool is simple with no parameters, but there is no output schema and the description does not clarify what 'statistics' includes. For a stats tool, some indication of returned data would help, but the low complexity keeps this from being a major gap.
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?
The tool has zero parameters and the schema is empty, matching the baseline of 4 for no parameters. There is nothing to explain, and the description does not mislead about parameters.
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 uses a specific verb 'Get' and a clear resource 'MCP server loader statistics', which clearly distinguishes it from sibling tools like list, start, stop, and restart. It is immediately apparent what the tool does.
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?
There is no guidance on when to use this tool versus the many sibling MCP server management tools. No context is given about scenarios where statistics would be needed, nor any exclusions such as 'use mcp_servers_list instead for server status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running MCP server
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Server name to stop |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Stop a running MCP server' but does not mention side effects (e.g., whether the server process is killed, whether configuration persists), reversibility, permissions required, or error outcomes. For a mutation operation, this leaves significant behavioral ambiguity.
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 a single six-word sentence that is front-loaded with the action verb and contains zero wasted words. It is appropriately sized for its purpose and immediately communicative.
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?
The tool has a minimal schema (one parameter) but no output schema or annotations. The terse description does not explain what happens after stopping, whether the server remains listed, how errors are handled, or what the tool returns. This is under-specified for an agent to fully understand the tool's behavior and consequences, even though the operation is conceptually simple.
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?
The schema already documents the sole parameter 'name' with the description 'Server name to stop', achieving 100% schema coverage. The tool description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate since the schema fully defines the parameter's purpose.
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 uses the specific verb 'Stop' with a clear object 'a running MCP server', unambiguously identifying the tool's action and resource. This distinguishes it from sibling tools like mcp_servers_start, mcp_servers_restart, and mcp_servers_remove, which act on the same server type but with different operations.
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 no guidance on when to use this tool versus alternatives such as mcp_servers_restart, mcp_servers_remove, or skill_mcp_stop. It does not state that the server must be running, whether the server remains configured but stopped, or any other contextual conditions that would help an agent choose this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | 메모리 타입: goal(목표), decision(결정사항), context(일반 컨텍스트) | |
| content | Yes | 저장할 내용 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | 초기화 확인 (true로 설정해야 실행) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | 조회할 타입 (기본: all) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| agenda | Yes | 토론 안건 | |
| context | No | 추가 컨텍스트 | |
| skip_cache | No | 캐시 사용 안 함 | |
| participants | No | 수동 참가자 목록 | |
| repeat_count | No | 종합 후 다시 묻는 반복 횟수 | |
| participant_count | No | 자동 페르소나 모드일 때 사용할 AI 수 | |
| include_transcript | No | 라운드별 응답 포함 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | The task to execute (describe what you want to accomplish) | |
| intent_hint | No | Optional hint for task classification (auto-detected if not provided) | |
| max_attempts | No | Maximum implementation attempts before escalation (default: 3) | |
| use_ralph_loop | No | Enable Ralph Loop mode for iterative task completion (auto-retry until done) | |
| timeout_minutes | No | Overall workflow timeout in minutes (default: 10) | |
| skip_exploration | No | Skip the exploration phase (faster but less context) | |
| ralph_max_iterations | No | Max Ralph Loop iterations (default: 10, only used when use_ralph_loop=true) | |
| ralph_completion_promise | No | Completion promise text for Ralph Loop (default: "DONE") | DONE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| expert | No | 작업에 사용할 전문가 (기본: strategist) | strategist |
| prompt | Yes | 작업 내용 (최소 10자) | |
| context | No | 추가 컨텍스트 정보 | |
| max_iterations | No | 최대 반복 횟수 (기본: 10, 최대: 50) | |
| completion_promise | No | 완료 시 출력할 프라미스 텍스트 (기본: "DONE") | DONE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | 조사 깊이 | normal |
| topic | Yes | 조사 주제 | |
| context | No | 추가 컨텍스트 (프로젝트 정보 등) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | 인라인 코드 (기존 호환) | |
| files | No | 리뷰할 파일 경로 (CLI가 직접 읽음, 상대경로만) | |
| focus | No | 집중할 리뷰 영역 (perspectives=1일 때 적용) | all |
| language | No | 프로그래밍 언어 (자동 감지) | |
| parallel | No | [deprecated] 항상 병렬 실행 | |
| context_docs | No | 리뷰 전 필수 읽기 문서 경로 (CLI가 직접 읽음, 상대경로만) | |
| perspectives | No | 리뷰 관점 수 (1: 버그/보안, 2: +아키텍처, 3: +비판적). 각 관점마다 GPT 1 에이전트 | |
| include_strategist | No | [deprecated] perspectives 사용 권장 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 작업 내용 | |
| context | No | 추가 컨텍스트 | |
| category | Yes | 작업 카테고리 | |
| override_expert | No | 카테고리 기본 전문가 대신 사용할 전문가 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Agent name or ID | |
| task | Yes | Task to give to the agent | |
| context | No | Additional context for the agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Input/arguments for the command | |
| command | Yes | Command name or slash command (e.g., "/review" or "git:commit") | |
| context | No | Additional context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | 추가 검색어 | |
| library_name | Yes | 검색할 라이브러리 이름 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 실행할 액션: status(상태 조회), reset(초기화), config(설정 변경) | |
| auto_retry | No | 자동 재시도 활성화 여부 (config 액션용) | |
| circuit_breaker_threshold | No | 서킷 브레이커 임계값 (config 액션용) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | 새로운 모델 이름 (예: gpt-4o, claude-sonnet-4, gemini-2.0-pro) | |
| expert | Yes | 변경할 전문가 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate a skill (enable and optionally start MCP)
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | Skill ID or name to activate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavior. It mentions 'enable and optionally start MCP', which is vague because the schema has no parameter to control the 'optionally' part. It also does not disclose side effects, reversibility, or prerequisites. This lack of detail leaves significant ambiguity.
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 a single concise sentence that front-loads the core purpose. Every word contributes meaning without redundancy, making it efficient and easy to parse.
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?
For a simple one-parameter tool, the description covers the basic function but lacks important context, such as when to prefer this over similar skill tools, the exact behavior of 'optionally start MCP', and expected results. The absence of usage guidance and behavioral details reduces completeness for an AI agent selecting among many related tools.
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 coverage is 100% with skill_id described as 'Skill ID or name to activate'. The description does not add any additional meaning beyond the schema, so the baseline of 3 is appropriate since the schema already provides full parameter documentation.
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 verb 'Activate' and the resource 'a skill', and clarifies the meaning with 'enable and optionally start MCP'. This distinguishes it from related sibling tools like skill_execute (which runs a skill) and skill_mcp_start (which specifically manages MCP servers).
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 implies when to use the tool (when you want to activate a skill by enabling it and possibly starting MCP), but it does not explicitly state when not to use it or mention alternatives like skill_execute or skill_mcp_start. This is an implied usage rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivate a skill (disable and stop MCP)
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | Skill ID or name to deactivate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses that deactivation disables and stops MCP, which adds behavioral context. However, it does not mention reversibility, permissions, or side effects, so it remains minimal.
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 a single sentence, directly front-loaded with the action and resource. No extraneous information.
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?
For a simple one-parameter tool with no output schema, the description sufficiently explains the core action. The lack of explicit usage guidance compared to sibling tools is a minor gap, but the low complexity makes this acceptable.
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?
The schema already provides a description for skill_id ('Skill ID or name to deactivate'), covering 100% of the parameter. The tool description does not add further semantic details, so baseline 3 applies.
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 uses a specific verb 'Deactivate' and identifies the resource 'skill', adding that it disables and stops MCP. This clearly differentiates it from sibling tools like skill_activate and skill_mcp_stop.
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 implies the tool is for deactivating skills, but it does not explicitly state when to use it over alternatives like skill_mcp_stop or skill_activate. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a skill with given input
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Input/prompt for the skill | |
| context | No | Additional context variables | |
| skill_id | Yes | Skill ID or name to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It doesn't disclose any side effects, whether execution is synchronous, error handling, or permissions. 'Execute' implies an action, but the description gives no context about what happens during execution or what output to expect.
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 a single sentence with no wasted words. It is front-loaded and efficient, but arguably too terse for a tool with multiple parameters. Still, for what it conveys, it is concise.
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?
The tool has no annotations and no output schema, and the description is minimal. It doesn't cover return values, exceptions, or whether the skill runs asynchronously. For an execution tool, this is a significant gap, making it incomplete for an agent to use confidently.
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%, so the schema already documents all parameters. The description adds no additional meaning beyond 'given input', which is redundant with the schema. Baseline 3 is appropriate since the schema handles semantic load.
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 uses a specific verb 'Execute' with a clear resource 'a skill' and mentions the required input. It distinguishes from sibling tools like skill_activate or skill_deactivate by implying a one-time run rather than activation state. However, it doesn't explicitly contrast with alternatives, so it falls short of a 5.
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?
There is no guidance on when to use this tool vs alternatives like skill_activate or command_execute. The description only states what it does, with no mention of prerequisites, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific skill
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | Skill ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Get' implies a read-only operation, but it does not disclose what 'detailed information' includes, whether it returns metadata/content, or any side effects. This is a basic but not misleading disclosure.
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 a single sentence with no filler. It is front-loaded with the verb and resource, making it efficient and scannable.
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?
The tool is simple with one parameter and no annotations or output schema. The description defines the core action but does not mention return format, possible errors, or what fields constitute 'detailed information', leaving some ambiguity for an agent.
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% for the single parameter skill_id, which is already described as 'Skill ID or name'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 uses a specific verb ('Get') and resource ('detailed information about a specific skill'), clearly distinguishing it from siblings like skill_list (which lists skills) and skill_execute (which runs a skill).
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?
No guidance is provided on when to use this tool instead of alternatives such as skill_list, skill_stats, or skill_execute. It does not state prerequisites, exclusions, or recommended contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available skills
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag | |
| scope | No | Filter by skill scope | all |
| enabled_only | No | Show only enabled skills |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'List' implies a read-only operation, but the description does not disclose the default behavior regarding enabled_only (default false) or scope (default all), nor does it describe what the list contains. There are no annotations to fall back on, so the description carries the burden but only vaguely covers behavioral details.
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 a single, focused sentence with no filler or redundancy. It is appropriately small and front-loaded with the action and resource.
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?
For a simple listing tool, the description plus the schema provides a complete picture: the action is clear, the filters are documented, and no output schema is needed for basic use. The only minor gap is the lack of explicit mention of return contents, but it is not a significant omission.
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%, so the schema fully documents all three parameters (tag, scope, enabled_only). The description adds no parameter information, but the baseline for high coverage is 3, which is appropriate here.
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 'List all available skills' uses a clear verb (list) and resource (skills), and it distinguishes the tool from sibling tools like skill_get, skill_execute, and skill_stats. It unambiguously states the core function.
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 implies usage for enumerating skills but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. Since listing is self-evident and sibling tools are distinct by name, the usage is implicitly clear but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start MCP server for a skill
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | Skill ID with MCP configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure, yet it only states 'Start MCP server for a skill' with no details on side effects, prerequisites, blocking behavior, error cases, or what happens after starting. This is essentially a restatement of the tool's name.
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 a single, front-loaded sentence with no waste. It is appropriately concise for a simple one-parameter tool, though it could have included more behavioral context without becoming verbose.
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 absence of annotations, output schema, and the minimal description, the tool lacks essential context such as success/failure behavior, prerequisites (e.g., skill must be activated), and how to verify the server started. For a start operation with no supporting structure, this is an incomplete description.
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 coverage is 100% with one parameter skill_id described as 'Skill ID with MCP configuration'. The tool description adds minimal context beyond the schema, merely reinforcing that the skill must have MCP configuration. This meets the baseline but does not enhance parameter understanding.
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 uses a specific verb 'Start' with a clear resource 'MCP server for a skill', conveying the tool's core function. However, it does not distinguish itself from related tools like skill_activate or mcp_servers_start, though the 'for a skill' qualifier provides some differentiation.
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?
No guidance is provided on when to use this tool versus alternatives such as skill_activate, skill_execute, or mcp_servers_start. The description implies usage for starting a skill's MCP server but does not state prerequisites, exclusions, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop MCP server for a skill
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | Skill ID with running MCP |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It states the action 'Stop MCP server' but does not disclose side effects on the skill, whether the operation is reversible, or error behavior when no MCP server is running for the skill.
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?
A single, front-loaded sentence that is appropriately concise for a simple stop operation. It contains no filler and is easily scannable.
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?
For a simple one-parameter tool with no output schema, the description is minimally viable but lacks usage context, differentiation from similar stop tools, and behavioral details such as return values or state changes. It provides the core purpose but little else.
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?
The input schema covers 100% of parameters, with skill_id described as 'Skill ID with running MCP'. The description itself adds no additional parameter guidance beyond the schema, so the schema does the heavy lifting.
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 uses a clear verb 'Stop' and identifies the resource as 'MCP server' with the scope 'for a skill'. This distinguishes it from sibling tools like mcp_servers_stop (which stops a general MCP server) and skill_mcp_start (which starts a server for a skill).
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 implies usage (when you want to stop a skill's MCP server), but it does not explicitly state when to use this tool versus the generic mcp_servers_stop or alternative tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload all skills from disk
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It only says 'reload all skills from disk' without mentioning side effects, permission requirements, return values, or potential disruption to currently active skills.
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 a single, front-loaded sentence with no redundant words. It is appropriately concise for a zero-parameter tool.
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?
While the tool is simple, the description omits important context for a reload operation, such as whether it refreshes configurations, cleans caches, or has any impact on running skills. No output schema or annotations exist to compensate, leaving the agent with gaps in expectations.
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?
There are no parameters, and schema coverage is complete. The description adds meaning by specifying the scope ('all skills'), which clarifies that the operation is global, not targeted at a single skill.
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 'Reload all skills from disk' clearly states a specific action (reload) applied to a specific resource (all skills). It distinguishes from sibling tools like skill_list, skill_get, and skill_execute by focusing on the reload operation.
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?
No guidance is provided on when to use this tool versus alternatives or when not to use it. The description merely states the action, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get skill system statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. 'Get' implies a read-only operation, but it does not explain what statistics are included, whether any state is affected, or what the output structure looks like. It adds minimal behavioral context beyond the verb.
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 a single, front-loaded sentence with no filler. It communicates the core action and resource efficiently without wasting words.
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 tool has no parameters, no output schema, and no annotations, the description is the only source of information. It is too vague to be fully complete—what statistics are provided? What do they represent? It could still be sufficient for a simple use case, but the lack of detail about the return value and when to use it leaves gaps.
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?
The tool has zero parameters, so the schema coverage is complete (100%). The description offers no parameter insights, but none are needed. Per the rubric, 0 params earns a baseline of 4, and the description does not detract from this.
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 action ('Get') and the resource ('skill system statistics'). It is a specific verb+resource pair, though 'statistics' is generic and could be more precise about what metrics are returned. It distinguishes from sibling skills tools by focusing on statistics rather than listing, executing, or managing skills.
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 no guidance on when to use this tool versus the many sibling skill-related tools (e.g., skill_list, skill_get, skill_execute). There is no mention of use cases, prerequisites, or alternatives. Users are left to infer the purpose from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 실행할 액션: status(상태), clear(항목 삭제), reset(초기화), complete(항목 완료) | |
| item_index | No | 완료할 항목 인덱스 (complete 액션용) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| response_reserve | No | 응답 예약 비율 (기본: 0.3) | |
| max_output_length | No | 최대 출력 길이 (기본: 50000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 검색 쿼리 | |
| category | No | 검색 카테고리 필터 | |
| end_date | No | 종료 날짜 (ISO 형식: 2024-12-31) | |
| start_date | No | 시작 날짜 (ISO 형식: 2024-01-01) | |
| num_results | No | 반환할 결과 수 (기본: 5, 최대: 20) | |
| exclude_domains | No | 제외할 도메인 목록 | |
| include_domains | No | 포함할 도메인 목록 (예: ['github.com', 'stackoverflow.com']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.4.5background_expert_cancelbackground_expert_listbackground_expert_resultbackground_expert_startcommand_configcommand_executecommand_getcommand_listcommand_rescancomment_checkerconsult_expertconsult_experts_parallelcontext_configcontext_statusdelegate_taskdesign_with_expertsdirectory_injectoredit_recoveryensemble_presetensemble_presets_listensemble_queryget_library_docsgit_atomic_commitgit_branch_analysisgit_history_searchgit_rebase_plannergit_squash_helpergrep_appgrep_app_languagesinteractive_bash_createinteractive_bash_killinteractive_bash_listinteractive_bash_readinteractive_bash_sendlist_agentslist_commandsllm_router_healthmagic_keywordsmcp_servers_addmcp_servers_getmcp_servers_listmcp_servers_reloadmcp_servers_removemcp_servers_restartmcp_servers_startmcp_servers_statsmcp_servers_stopmemory_addmemory_clearmemory_listmoderated_debateorchestrate_taskralph_loop_cancelralph_loop_startralph_loop_statusresearch_topicreview_coderoute_by_categoryrun_agentrun_commandsearch_commandssearch_librariessession_recoveryset_expert_modelskill_activateskill_deactivateskill_executeskill_getskill_listskill_mcp_startskill_mcp_stopskill_reloadskill_statstodo_enforcertruncator_configweb_searchMany tools have overlapping purposes (e.g., command_execute, run_command, run_agent; skill_activate, skill_execute; background_expert_start/cancel/list). With most descriptions blank, agents cannot reliably distinguish between similar tools.
The toolkit generally uses snake_case and often follows group_prefix_action (mcp_servers_*, skill_*), but there are inconsistencies like background_expert_result, ralph_loop_cancel, and noun-only names (magic_keywords, grep_app). Overall a mixed but readable convention.
76 tools is extreme for a single server, exceeding the 50+ threshold. The toolkit appears to bundle unrelated domains (routing, git, bash, memory, skills, MCP management) into one surface, making it unwieldy.
While some areas (skills, MCP servers) have extensive coverage, others are incomplete (memory has add/list/clear but no update/delete, no clear routing/model management tools). The lack of descriptions makes it impossible to trust the surface covers its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
Coding agents from Claude Code, Cursor and Codex claim jobs and lock files on one shared board.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kijun0708/llm-router-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
