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

Claude-Code-MCP-Projekt

[0.1.3] - 08.05.2025

Geändert

Verbesserte Sicherheit durch strenge Validierung der Umgebungsvariable CLAUDE_BIN . Der Server überprüft nun vor der Verwendung Pfad, Name, Existenz und Berechtigungen der ausführbaren Datei.

Behoben

Eine potenzielle Sicherheitslücke bei der Befehlseingabe im Zusammenhang mit der Umgebungsvariable CLAUDE_BIN wurde behoben.

Related MCP server: MCP Practice

Überblick

Das Claude-Code-MCP-Projekt ist ein MCP-Server für Claude Code.

Es ruft den lokal installierten Claude Code-Befehl auf und bietet die folgenden Tools: explain_code , review_code , fix_code , edit_code , test_code , simulate_command und your_own_query . Der Server wird mit Node.js und dem MCP SDK implementiert und empfängt Anfragen im JSON-Format von Clients über stdio. Intern verwendet er Base64-Kodierung, um Sonderzeichen (Zeilenumbrüche, Anführungszeichen usw.) in natürlichsprachlichem Text reibungslos zu verarbeiten, was zu verbesserter Stabilität und Flexibilität führt. Seine Hauptaufgaben sind das Empfangen von Anfragen, das Kodieren von Eingaben, das Generieren und Ausführen von Befehlen sowie das Zurückgeben von Ausführungsergebnissen im JSON-Format. Es wurde bestätigt, dass dieses Projekt in Claude Code CLI-Umgebungen (Ubuntu/WSL2 usw.) funktioniert.

💡 MCP-Host mit weniger leistungsfähigem LLM kann Claudes Leistung zähmen und nutzen💪! Mit claude-code-mcp kannst du Claude Code auch von Claude Desktop aus aufrufen!! 😇😜😎 (unbestätigt)

Funktionen

Die Hauptrollen des Servers sind:

Anforderungsempfang: Empfangen Sie Toolanforderungen im JSON-Format von Clients (z. B. code , context , focus_areas usw.).
Eingabeverarbeitung: Der empfangene Text in natürlicher Sprache wird intern mit Base64 kodiert.
Werkzeugauswahl und Befehlsgenerierung: Stellen Sie basierend auf dem Werkzeugnamen in der Anforderung eine Befehlszeichenfolge für die Abfrage zusammen. Verwenden Sie dazu eine feste Vorlage oder ein freies Format ( your_own_query ).
Befehlsausführung: Verwenden Sie child_process.spawn von Node.js, um den zusammengestellten Befehl auszuführen und das Ergebnis aus der Standardausgabe abzurufen.
Ergebnisrückgabe: Gibt das Ausführungsergebnis im JSON-Format an den Client zurück.

Erste Schritte

Voraussetzungen

Node.js (>= v18 empfohlen, getestet mit v22.14.0)
npm (oder Garn)
Claude Code-Befehl installiert und Authentifizierung abgeschlossen. https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview

Installation und Verwendung

Es gibt mehrere Möglichkeiten claude-code-mcp zu verwenden:

1. Verwenden von npx (empfohlen für den schnellen Einsatz)

Sie können den Server ohne Installation direkt mit npx ausführen:

npx @kunihiros/claude-code-mcp

2. Globale Installation

Installieren Sie das Paket global:

npm install -g claude-code-mcp

Anschließend können Sie es als Befehl ausführen:

claude-code-mcp

3. Lokale Installation (für die Entwicklung)

Klonen Sie das Repository und installieren Sie Abhängigkeiten:

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

Sie können das erstellte Skript dann direkt ausführen:

node build/index.js

Konfiguration

Umgebungsvariablen:

Unabhängig von der Installationsmethode müssen Sie die Umgebungsvariablen konfigurieren. Erstellen Sie eine der folgenden Dateien:

Verwenden der MCP-Host-Einstellungen (empfohlen für npx ): Konfigurieren Sie Umgebungsvariablen direkt in den Einstellungen Ihres MCP-Hosts (siehe „MCP-Host-Konfiguration“ weiter unten). Dies ist der einfachste Weg bei Verwendung npx .
Verwenden einer .env Datei: Erstellen Sie eine .env Datei in dem Verzeichnis, in dem Sie den npx @kunihiros/claude-code-mcp ausführen.
Verwenden einer globalen Konfigurationsdatei: Erstellen Sie eine Datei .claude-code-mcp.env in Ihrem Home-Verzeichnis ( ~/.claude-code-mcp.env ).

Wenn Sie eine Datei ( .env oder ~/.claude-code-mcp.env ) verwenden, fügen Sie den folgenden Inhalt hinzu und passen Sie den CLAUDE_BIN Pfad an:

# .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-Hostkonfiguration (empfohlen für npx ):

Fügen Sie Folgendes zu den Einstellungen Ihrer MCP-Hostanwendung hinzu (z. B. zu den Claude-Desktop-Einstellungen). Mit dieser Methode können Sie Umgebungsvariablen direkt festlegen.

    "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
    }

(Möglicherweise ist ein Neustart der Hostanwendung erforderlich.)

Alternative MCP-Hostkonfiguration (Globale Installation / Lokale Entwicklung):

Wenn Sie das Paket global installiert haben oder es lokal aus dem geklonten Repository ausführen und sich der Befehl claude-code-mcp im PATH Ihres Systems befindet, können Sie Folgendes verwenden:

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

In diesem Fall müssen Sie Umgebungsvariablen mithilfe einer .env Datei oder der globalen Datei ~/.claude-code-mcp.env konfigurieren, wie oben beschrieben.

Details zu Umgebungsvariablen

Dieser Server verwendet die folgenden Umgebungsvariablen (festgelegt über die MCP-Host env , .env oder ~/.claude-code-mcp.env ):

CLAUDE_BIN : Gibt den Pfad zur ausführbaren Datei der Claude-CLI an. (Erforderlich) Beispiel: /home/linuxbrew/.linuxbrew/bin/claude oder C:\Users\YourUser\AppData\Local\bin\claude.exe
LOG_LEVEL : Gibt die Protokollebene an. (Optional, standardmäßig info “). Mögliche Werte: debug , info , warn , error .

Verfügbare Tools

Der claude-code-mcp Server bietet die folgenden Tools:

explain_code : Bietet eine detaillierte Erklärung des angegebenen Codes.
review_code : Überprüft den angegebenen Code.
fix_code : Behebt Fehler oder Probleme im angegebenen Code.
edit_code : Bearbeitet den angegebenen Code basierend auf Anweisungen.
test_code : Generiert Tests für den angegebenen Code.
simulate_command : Simuliert die Ausführung eines bestimmten Befehls.
your_own_query : Sendet eine benutzerdefinierte Abfrage mit Kontext.

Notiz

Speicherort der Protokolldatei ( claude-code-mcp.log ):
- Versucht zuerst, es im Projektstamm zu erstellen.
- Fällt auf das Home-Verzeichnis des Benutzers zurück ( ~/.claude-code-mcp.log ).
- Fällt schließlich auf /tmp/claude-code-mcp.log zurück.
Die Protokollrotation ist noch nicht implementiert (achten Sie auf die Größe der Protokolldatei).
Hauptsächlich mit Claude CLI auf Ubuntu/WSL2 getestet.

Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert – Einzelheiten siehe unten.

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.

Haftungsausschluss

Diese Software dient ausschließlich Bildungs- und Forschungszwecken. Dieses Projekt steht in keiner offiziellen Verbindung zu Anthropic und wird auch nicht von Anthropic unterstützt. Claude ist eine Marke von Anthropic.

Das Projekt nutzt die Claude CLI als Abhängigkeit, ist aber ein unabhängiges, von der Community betriebenes Projekt. Nutzer sollten bei der Nutzung dieses Projekts die Nutzungsbedingungen von Anthropic einhalten.

Die Betreuer dieses Projekts sind nicht für den Missbrauch der Software oder Verstöße gegen die Nutzungsbedingungen von APIs oder Diensten Dritter verantwortlich.

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

Claude-Code-MCP-Projekt

[0.1.3] - 08.05.2025

Geändert

Behoben

Überblick

Funktionen

Erste Schritte

Voraussetzungen

Installation und Verwendung

Konfiguration

Details zu Umgebungsvariablen

Verfügbare Tools

Notiz

Lizenz

Haftungsausschluss

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches