de en es ja ko ru zh

claude-code-mcp

Name: claude-code-mcp
Author: KunihiroS

by KunihiroS

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

클로드-코드-mcp 프로젝트

업데이트

이제 이 MCP 서버는 npx를 통한 로컬 설치 없이도 작동합니다!!

Related MCP server: MCP Practice

개요

claude-code-mcp 프로젝트는 Claude Code의 MCP 서버입니다.

로컬에 설치된 Claude Code 명령을 호출하고 explain_code , review_code , fix_code , edit_code , test_code , simulate_command , your_own_query 등의 도구를 제공합니다. 이 서버는 Node.js와 MCP SDK를 사용하여 구현되었으며, stdio를 통해 클라이언트로부터 JSON 형식 요청을 받습니다. 내부적으로는 Base64 인코딩을 사용하여 자연어 텍스트의 특수 문자(줄바꿈, 따옴표 등)를 원활하게 처리하여 안정성과 유연성을 향상시킵니다. 주요 역할은 요청 수신, 입력 인코딩, 명령 생성 및 실행, 그리고 JSON 형식으로 실행 결과를 반환하는 것입니다. 이 프로젝트는 Claude Code CLI 환경(Ubuntu/WSL2 등)에서 작동하는 것으로 확인되었습니다.

💡 LLM 성능이 떨어지는 MCP 호스트도 클로드의 힘을 길들이고 활용할 수 있습니다💪! claude-code-mcp를 사용하면 클로드 데스크톱에서 클로드 코드를 호출할 수도 있습니다!! 😇😜😎 (미확인)

기능

서버의 주요 역할은 다음과 같습니다.

요청 수신: 클라이언트로부터 JSON 형식 도구 요청을 수신합니다(예: code , context , focus_areas 등).
입력 처리: 수신된 자연어 텍스트를 내부적으로 Base64로 인코딩합니다.
도구 선택 및 명령 생성: 요청의 도구 이름을 기반으로 고정 템플릿이나 자유 형식( your_own_query )을 사용하여 쿼리에 대한 명령 문자열을 조립합니다.
명령 실행: Node.js의 child_process.spawn 사용하여 조립된 명령을 실행하고 표준 출력에서 결과를 얻습니다.
결과 반환: 실행 결과를 JSON 형식으로 클라이언트에 반환합니다.

시작하기

필수 조건

Node.js(v18 이상 권장, v22.14.0으로 테스트)
npm(또는 yarn)
Claude Code 명령이 설치되고 인증이 완료되었습니다. https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview

설치 및 사용

claude-code-mcp 사용하는 방법에는 여러 가지가 있습니다.

1. npx 사용 (빠른 사용을 위해 권장)

npx 사용하면 설치 없이 서버를 직접 실행할 수 있습니다.

지엑스피1

2. 글로벌 설치

패키지를 전역으로 설치합니다.

npm install -g claude-code-mcp

그런 다음 명령으로 실행할 수 있습니다.

claude-code-mcp

3. 로컬 설치(개발용)

저장소를 복제하고 종속성을 설치합니다.

git clone https://github.com/KunihiroS/claude-code-mcp.git
cd claude-code-mcp/claude-code-server
npm install
npm run build

그런 다음 빌드된 스크립트를 직접 실행할 수 있습니다.

node build/index.js

구성

환경 변수:

설치 방법에 관계없이 환경 변수를 구성해야 합니다. 다음 파일 중 하나를 생성하세요.

MCP 호스트 설정 사용( npx 권장): MCP 호스트 설정에서 직접 환경 변수를 구성하세요(아래 "MCP 호스트 구성" 참조). npx 사용할 때 가장 쉬운 방법입니다.
.env 파일 사용: npx @kunihiros/claude-code-mcp 명령을 실행하는 디렉토리에 .env 파일을 만듭니다.
글로벌 구성 파일 사용: 홈 디렉토리( ~/.claude-code-mcp.env )에 .claude-code-mcp.env 파일을 만듭니다.

파일( .env 또는 ~/.claude-code-mcp.env )을 사용하는 경우 다음 내용을 추가하고 CLAUDE_BIN 경로를 조정합니다.

# .env or ~/.claude-code-mcp.env
CLAUDE_BIN=/path/to/your/claude/executable  # REQUIRED: Set the full path to your Claude CLI
LOG_LEVEL=info                             # Optional: Set log level (e.g., debug, info, warn, error)

MCP 호스트 구성( npx 에 권장):

MCP 호스트 애플리케이션 설정(예: Claude Desktop 설정)에 다음을 추가하세요. 이 방법을 사용하면 환경 변수를 직접 설정할 수 있습니다.

    "claude-code-server": {
      "command": "npx",
      "args": [
        "-y",
        "@kunihiros/claude-code-mcp"
      ],
      "env": {
        "CLAUDE_BIN": "/path/to/your/claude/executable", // REQUIRED: Set the absolute path
        "LOG_LEVEL": "info"                             // Optional: Set log level
      },
      "disabled": false
    }

(호스트 애플리케이션을 다시 시작해야 할 수도 있습니다.)

대체 MCP 호스트 구성(글로벌 설치/로컬 개발):

패키지를 전역적으로 설치했거나 복제된 저장소에서 로컬로 실행 중이고 claude-code-mcp 명령이 시스템의 PATH에 있는 경우 다음을 사용할 수 있습니다.

    "claude-code-server": {
      "command": "claude-code-mcp",
      "disabled": false
    }

이 경우 위에서 설명한 대로 .env 파일이나 글로벌 ~/.claude-code-mcp.env 파일을 사용하여 환경 변수를 구성 해야 합니다 .

환경 변수 세부 정보

이 서버는 다음 환경 변수를 사용합니다(MCP 호스트 env 설정, .env 또는 ~/.claude-code-mcp.env 를 통해 설정됨):

CLAUDE_BIN : Claude CLI 실행 파일의 경로를 지정합니다. (필수) 예: /home/linuxbrew/.linuxbrew/bin/claude 또는 C:\Users\YourUser\AppData\Local\bin\claude.exe
LOG_LEVEL : 로그 수준을 지정합니다. (선택 사항, 기본값은 info 입니다.) 가능한 값: debug , info , warn , error .

사용 가능한 도구

claude-code-mcp 서버는 다음과 같은 도구를 제공합니다.

explain_code : 주어진 코드에 대한 자세한 설명을 제공합니다.
review_code : 주어진 코드를 검토합니다.
fix_code : 주어진 코드의 버그나 문제를 수정합니다.
edit_code : 지침에 따라 주어진 코드를 편집합니다.
test_code : 주어진 코드에 대한 테스트를 생성합니다.
simulate_command : 주어진 명령의 실행을 시뮬레이션합니다.
your_own_query : 컨텍스트를 포함한 사용자 정의 쿼리를 보냅니다.

메모

로그 파일( claude-code-mcp.log ) 위치:
- 먼저 프로젝트 루트에 생성을 시도합니다.
- 사용자의 홈 디렉토리( ~/.claude-code-mcp.log )로 돌아갑니다.
- 마지막으로 /tmp/claude-code-mcp.log 로 돌아갑니다.
로그 회전은 아직 구현되지 않았습니다(로그 파일 크기에 주의하세요).
주로 Ubuntu/WSL2에서 Claude CLI로 테스트되었습니다.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 아래를 참조하세요.

MIT License

Copyright (c) 2024 KunihiroS

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

부인 성명

이 소프트웨어는 교육 및 연구 목적으로만 제공됩니다. 이 프로젝트는 Anthropic과 공식적으로 제휴하거나 보증하지 않습니다. Claude는 Anthropic의 상표입니다.

이 프로젝트는 Claude CLI를 종속성으로 사용하지만, 독립적인 커뮤니티 주도 프로젝트입니다. 사용자는 이 프로젝트를 사용할 때 Anthropic의 서비스 약관을 준수해야 합니다.

이 프로젝트의 유지 관리자는 소프트웨어의 오용이나 제3자 API 또는 서비스의 서비스 약관 위반에 대해 책임을 지지 않습니다.

Available Tools

7 tools

edit_codeC

Edits the given code based on instructions.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Code to edit
`instructions`	Yes	Editing instructions

TDQS

C2.6/5.0

Behavior2/5

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 states the tool edits code but doesn't explain how—whether it's a direct mutation, requires permissions, has side effects, or what the output looks like. For a tool that modifies code without annotations, this leaves critical behavioral traits unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. There's no wasted language, making it concise.

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

Completeness2/5

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

Given the complexity of editing code, lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like mutation safety, error handling, or result format, which are essential for an agent to use this tool correctly. The description fails to compensate for the missing structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with clear documentation for both parameters ('code' and 'instructions'). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

Purpose3/5

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

The description states the tool's purpose as editing code based on instructions, which is clear but vague. It specifies the verb ('edits') and resource ('code'), but doesn't distinguish it from sibling tools like 'fix_code' or 'review_code' that might also modify code. The purpose is understandable but lacks specificity about what type of editing it performs.

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

Usage Guidelines2/5

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. With siblings like 'fix_code', 'review_code', and 'explain_code', there's no indication whether this is for general code modifications, bug fixes, or something else. No prerequisites, exclusions, or comparative context are mentioned.

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

explain_codeC

Provides detailed explanation of the given code.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Target code
`context`	No	Additional context

TDQS

C2.6/5.0

Behavior2/5

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 mentions 'detailed explanation' but doesn't disclose behavioral traits like response format, depth of analysis, potential rate limits, or error conditions. This is inadequate for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. Every sentence earns its place, but it's slightly under-specified.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the explanation includes (e.g., syntax, logic, dependencies) or the return format. For a code explanation tool with rich potential outputs, this lacks necessary context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('code' and 'context'). The description adds no meaning beyond what the schema provides, such as examples or usage tips. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose3/5

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

The description states the tool 'provides detailed explanation of the given code,' which clearly indicates its function. However, it doesn't differentiate from siblings like 'review_code' or 'fix_code' that might also involve code analysis. The purpose is clear but lacks sibling distinction.

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

Usage Guidelines2/5

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 'review_code' or 'fix_code.' The description implies usage for code explanation but offers no context on prerequisites, exclusions, or comparisons to sibling tools.

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

fix_codeC

Fixes bugs or issues in the given code.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Code to fix
`issue_description`	Yes	Description of the issue

TDQS

C2.9/5.0

Behavior2/5

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 states the tool 'fixes bugs or issues' but doesn't explain how it behaves—e.g., whether it modifies code in place, returns suggestions, requires specific permissions, or has rate limits. This leaves critical operational details unclear 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence: 'Fixes bugs or issues in the given code.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity.

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

Completeness2/5

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

Given the complexity of a code-fixing tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, output format, error handling, or how it interacts with siblings. This makes it inadequate for an agent to use the tool effectively without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with clear documentation for 'code' and 'issue_description'. The description adds no additional meaning beyond what the schema provides, such as examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3, which applies here.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Fixes bugs or issues in the given code.' It specifies the verb ('fixes') and resource ('bugs or issues in the given code'), making the intent understandable. However, it doesn't explicitly differentiate from sibling tools like 'edit_code' or 'review_code', which might have overlapping purposes, preventing a perfect score.

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

Usage Guidelines2/5

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 prerequisites, exclusions, or compare it to siblings such as 'edit_code' or 'test_code'. Without this context, an agent might struggle to select the appropriate tool for code-related tasks.

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

review_codeD

Reviews the given code.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Code to review
`focus_areas`	No	Areas to focus on

TDQS

D1.7/5.0

Behavior1/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers none. 'Reviews the given code' doesn't reveal whether this is a read-only analysis, whether it modifies code, what permissions might be needed, what format the review takes, or any limitations. For a tool that presumably analyzes code, this lack of behavioral context is completely inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While technically concise with just 4 words, this is under-specification rather than effective conciseness. The single sentence 'Reviews the given code' fails to provide necessary information that would help an agent use the tool correctly. Every word should earn its place, but here the minimal text creates ambiguity rather than clarity.

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

Completeness1/5

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

Given the complexity of code review (which could involve security, performance, style, correctness, etc.) and the presence of multiple sibling tools with overlapping functions, this description is completely inadequate. With no annotations, no output schema, and multiple similar tools available, the description fails to provide the contextual information needed to select and use this tool appropriately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('code' and 'focus_areas') adequately. The description adds no parameter information beyond what the schema provides - it doesn't explain what constitutes valid 'focus_areas' or how they affect the review. Baseline 3 is appropriate when the schema does the heavy lifting, though the description adds zero value.

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

Purpose2/5

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

The description 'Reviews the given code' is a tautology that restates the tool name 'review_code' without adding meaningful specificity. It doesn't distinguish this tool from siblings like 'explain_code' or 'fix_code' - both could involve reviewing code. The description lacks a clear verb+resource combination that defines what 'reviewing' entails versus other code analysis operations.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance about when to use this tool versus alternatives. With siblings like 'explain_code', 'fix_code', and 'test_code' available, there's no indication whether this tool is for code quality assessment, security review, performance analysis, or general explanation. The agent receives no help in selecting between these closely related code analysis tools.

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

simulate_commandC

Simulates the execution of a given command.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	Command to execute
`input`	No	Input data

TDQS

C2.7/5.0

Behavior2/5

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 states the tool simulates execution but doesn't clarify what 'simulates' entails—e.g., whether it's a dry run, sandboxed execution, or mock output—nor does it address permissions, side effects, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste, making it appropriately sized and front-loaded. Every word contributes directly to stating the tool's purpose.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete for a tool that simulates commands. It doesn't explain what the simulation returns, potential errors, or how it differs from actual execution, leaving significant gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional meaning beyond the schema, such as examples or constraints, so it meets the baseline for high schema coverage without compensating further.

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

Purpose3/5

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

The description states the tool 'simulates the execution of a given command,' which provides a basic verb+action but lacks specificity about what type of command or simulation is involved. It doesn't differentiate from sibling tools like 'test_code' or 'your_own_query,' making it vague in context.

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

Usage Guidelines2/5

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. The description doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

test_codeC

Generates tests for the given code.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Code to test
`test_framework`	No	Test framework to use

TDQS

C2.9/5.0

Behavior2/5

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 states what the tool does ('generates tests') but doesn't explain how it behaves—e.g., whether it overwrites existing tests, requires specific permissions, handles errors, or produces structured output. This is a significant gap for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the complexity of generating tests (which could involve language-specific frameworks or output formats), the lack of annotations and output schema means the description is incomplete. It doesn't address behavioral aspects, return values, or error handling, leaving gaps for the agent to navigate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('code' and 'test_framework') adequately. The description doesn't add any meaning beyond what the schema provides, such as examples or constraints, but the high schema coverage justifies the baseline score of 3.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('generates') and resource ('tests for the given code'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'review_code' or 'fix_code', which might also involve testing-related functionality, so it doesn't reach the highest score.

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

Usage Guidelines2/5

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 like 'review_code' or 'fix_code'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based solely on the tool name and description.

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

your_own_queryC

Sends a custom query with context.

ParametersJSON Schema

Name	Required	Description	Default
`context`	No	Additional context
`query`	Yes	Query text

TDQS

C2.6/5.0

Behavior2/5

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 states the action ('sends a custom query with context') without explaining what happens after sending (e.g., response format, error handling, side effects, or rate limits). For a tool with no annotations, this is insufficient to inform the agent about its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence ('Sends a custom query with context.') that is front-loaded and wastes no words. However, it could be more structured by including key details, but it earns high marks for brevity and clarity within its limited scope.

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

Completeness2/5

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

Given the complexity (a query tool with no annotations and no output schema), the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or the context of use (e.g., related to code or commands). With siblings like code-related tools, more context is needed to guide the agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for both parameters ('query' as query text, 'context' as additional context). The description adds no additional meaning beyond the schema, such as examples or constraints. Since the schema does the heavy lifting, 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.

Purpose3/5

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

The description states the tool 'sends a custom query with context', which provides a basic verb+resource combination. However, it's vague about what type of query this is (e.g., database query, API query, natural language query) and doesn't distinguish it from sibling tools like 'simulate_command' or 'explain_code' that might also involve queries. The purpose is understandable but lacks specificity.

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

Usage Guidelines2/5

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. With siblings like 'explain_code' and 'simulate_command', it's unclear if this tool is for general-purpose queries or specific contexts. There are no explicit when/when-not instructions or named alternatives mentioned, leaving usage ambiguous.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0Apr 26, 2025
- First observededit_code
- First observedexplain_code
- First observedfix_code
- First observedreview_code
- First observedsimulate_command
- First observedtest_code
- First observedyour_own_query

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.7/5.0

Scored 2026-04-18 11:20 across 7 tools

Disambiguation3/5

There is significant overlap between edit_code, fix_code, and review_code, as all involve modifying or analyzing code for improvements, which could confuse an agent about which to use for specific tasks. However, explain_code, simulate_command, test_code, and your_own_query have more distinct purposes, providing some clarity.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (e.g., edit_code, explain_code, fix_code), which is predictable and readable. The only deviation is your_own_query, which uses a different style but doesn't severely disrupt the overall consistency.

Tool Count5/5

With 7 tools, the count is well-scoped for a code-focused server, falling within the typical 3-15 range. Each tool appears to serve a specific purpose in code development and analysis, making the set appropriately sized for the domain.

Completeness4/5

The tool set covers key aspects of code interaction such as editing, explaining, fixing, reviewing, simulating, testing, and custom queries, which aligns well with a code assistant domain. Minor gaps might include operations like code generation or version control integration, but core workflows are adequately supported.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
237
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

MCP Claude Code
Code Execution Shell Access File Systems
SDGLBL
A
license
A
quality
B
maintenance
An MCP server that implements Claude Code-like functionality, allowing the AI to analyze codebases, modify files, execute commands, and manage projects through direct file system interactions.
Updated a year ago (2025-08-29 13:41 UTC)
15
304
MIT
MCP Practice
Agent Orchestration Developer Tools
Ijongwon
A
license
C
quality
D
maintenance
A Model Context Protocol (MCP) server that demonstrates how to build and implement custom tools for Claude using the mcp-framework.
Updated a year ago (2025-08-04 09:02 UTC)
1
0
ISC
Example MCP Server
Developer Tools
VIGNESH-2232005
A
license
Not graded
quality
D
maintenance
A Node.js/TypeScript MCP server template with sample tools (ping and system_info) that demonstrates how to build custom tools for Claude Desktop using stdio transport.
Updated 10 months ago (2025-12-04 11:31 UTC)
4 npm
ISC
claudecode-mcp
Code Execution Developer Tools AI & Machine Learning
trevoraspencer
A
license
A
quality
B
maintenance
Local MCP server that wraps the headless Claude Code CLI as MCP tools, providing stateless access to Claude's coding capabilities through prompt-based interactions. It enables users to execute Claude Code commands with various prompt formats and structured outputs directly from MCP clients.
Updated 2 months ago (2026-07-28 11:02 UTC)
3
MIT

클로드-코드-mcp 프로젝트

업데이트

개요

기능

시작하기

필수 조건

설치 및 사용

구성

환경 변수 세부 정보

사용 가능한 도구

메모

특허

부인 성명

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches