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., "@MCP Dev MCP list tools on the remote weather server at https://weather.example.com/sse"
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.
LLMエージェントが他のMCPサーバーを開発、デバッグ、検査するためのMCPサーバーです。
MCP Inspector CLIの機能をラップし、エージェントが自身の環境から直接プログラム的に他のMCPサーバーの挙動（ツールの確認、リソースの読み取り、プロンプトのテスト）を検証できるようにします。
プログラムによる検査: ターゲットとなるMCPサーバーのツール一覧・実行、リソース一覧・読み取り、プロンプト一覧・取得が可能。
エージェントフレンドリー: LLMエージェントが自律的にMCPサーバーを開発・検証するために設計。
柔軟なトランスポート: stdio（ローカルコマンド実行）と sse/http（リモートURL接続）の両方に対応。
Related MCP server: mcp-cli-catalog
MCPクライアント（例: claude_desktop_config.json）の設定に追加してください：
{
"mcpServers": {
"mcpdev": {
"command": "npx",
"args": ["-y", "@kongyo2/mcpdevmcp"]
}
}
}すべてのツールは target 引数を受け取ります。これにはローカルの実行コマンドまたはリモートURLを指定できます。
mcpdev_inspector_list_toolsターゲットMCPサーバーで利用可能なすべてのツールを一覧表示します。
// 例: リモートサーバーを検査
{
"target": "https://mcp.deepwiki.com/sse",
"transport": "sse"
}mcpdev_inspector_call_toolターゲットMCPサーバー上の特定のツールを実行します。
// 例: ローカルサーバーのツールを実行
{
"target": "node ./my-server/dist/index.js",
"transport": "stdio",
"tool_name": "calculator",
"tool_args": { "a": 1, "b": 2, "op": "add" }
}mcpdev_inspector_list_resourcesターゲットMCPサーバーのリソース一覧を取得します。
mcpdev_inspector_read_resource特定のリソースの内容を読み取ります。
mcpdev_inspector_list_promptsターゲットMCPサーバーのプロンプト一覧を取得します。
mcpdev_inspector_get_prompt特定のプロンプトテンプレートを取得します。
このプロジェクトは、高品質かつモダンなTypeScriptのベストプラクティスに基づいて構築されています：
TypeScript: Strictモード, ES2022
エラーハンドリング: neverthrow を使用したResult型（ビジネスロジック内での例外スロー禁止）
Linting: oxlint による高速なLint
npm install
npm run build# Inspectorを使用して、このサーバー自身のツール一覧を取得
npx @modelcontextprotocol/inspector --cli --method tools/list node dist/index.jsMIT
Execute a tool on a target MCP server.
Use this to invoke a specific tool on the target server with provided arguments.
Args:
target (string): Target MCP server - command or URL
transport ('stdio' | 'sse' | 'http'): Transport type
timeout_ms (number): Timeout in milliseconds (default: 60000)
tool_name (string): Name of the tool to call
tool_args (object): Arguments to pass to the tool
Returns: The tool's response content.
Examples:
{ target: "node server.js", tool_name: "get_weather", tool_args: { city: "Tokyo" } }
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target MCP server - either a command (e.g., 'node server.js') or URL (e.g., 'https://example.com/sse') | |
| transport | No | Transport type: 'stdio' for local commands, 'sse' for SSE URLs, 'http' for streamable HTTP | |
| timeout_ms | No | Timeout in milliseconds (default: 60000) | |
| tool_name | Yes | Name of the tool to call | |
| tool_args | No | Arguments to pass to the tool |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it mentions the tool's response content and includes an example, which helps clarify behavior. Annotations indicate destructiveHint=true and openWorldHint=true, but the description doesn't contradict these; it supports them by describing execution with arguments. However, it doesn't detail potential side effects or error handling, leaving some gaps.
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 well-structured with clear sections (purpose, usage, args, returns, examples) and is front-loaded with the main purpose. It's concise overall, but the 'Args' section slightly duplicates schema information, though it's useful for quick reference. Every sentence adds value, such as the example clarifying practical use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, destructive operation, no output schema), the description is fairly complete: it explains the purpose, parameters, returns, and includes an example. However, it lacks details on error cases, response formats, or how to handle different transport types, which could be important for a tool with openWorldHint=true and destructiveHint=true.
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 parameters. The description lists parameters in the 'Args' section but doesn't add significant meaning beyond the schema, such as explaining interactions between parameters (e.g., how transport relates to target). It provides an example that illustrates usage, but this is more about guidelines than parameter semantics.
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: 'Execute a tool on a target MCP server' and 'invoke a specific tool on the target server with provided arguments.' It uses specific verbs ('execute', 'invoke') and identifies the resource ('target MCP server'), distinguishing it from sibling tools that list or read rather than execute.
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 by stating it's for executing tools on MCP servers, but it doesn't explicitly guide when to use this versus alternatives like the sibling tools (e.g., list_tools or read_resource). There's no mention of prerequisites, such as needing to know the tool name from list_tools, or exclusions for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific prompt from a target MCP server.
Use this to retrieve and render a prompt template with provided arguments.
Args:
target (string): Target MCP server - command or URL
transport ('stdio' | 'sse' | 'http'): Transport type
timeout_ms (number): Timeout in milliseconds (default: 60000)
prompt_name (string): Name of the prompt to get
prompt_args (object): Arguments to pass to the prompt template
Returns: The rendered prompt messages.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target MCP server - either a command (e.g., 'node server.js') or URL (e.g., 'https://example.com/sse') | |
| transport | No | Transport type: 'stdio' for local commands, 'sse' for SSE URLs, 'http' for streamable HTTP | |
| timeout_ms | No | Timeout in milliseconds (default: 60000) | |
| prompt_name | Yes | Name of the prompt to get | |
| prompt_args | No | Arguments to pass to the prompt template |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains that the tool renders prompts with arguments, which clarifies the 'prompt_args' parameter's purpose. Annotations already cover safety (readOnlyHint=true, destructiveHint=false) and idempotency, so the bar is lower. The description doesn't contradict annotations and adds useful operational context about rendering behavior.
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 perfectly concise and well-structured: a clear purpose statement in the first sentence, followed by a usage guideline in the second sentence. The Args/Returns sections are formatted but not part of the description text itself. Every sentence earns its place with zero waste.
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 moderate complexity (5 parameters, no output schema, rich annotations), the description is mostly complete. It explains the core purpose and rendering behavior well. However, it doesn't mention what happens if the prompt doesn't exist or if arguments are invalid, which could be helpful context despite the annotations covering safety aspects.
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 fully documents all 5 parameters. The description adds minimal value beyond the schema by mentioning 'provided arguments' for 'prompt_args', but doesn't provide additional syntax, format, or semantic details. This meets the baseline of 3 when schema coverage is complete.
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 with specific verbs ('Get', 'retrieve', 'render') and resource ('a specific prompt from a target MCP server'). It distinguishes from sibling tools like 'list_prompts' (which lists prompts) by specifying retrieval of a single prompt with template rendering.
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 clear context for when to use this tool ('to retrieve and render a prompt template with provided arguments'), but doesn't explicitly state when not to use it or name alternatives. It implies usage for rendering prompts rather than just listing them, but lacks explicit exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available prompts from a target MCP server.
Use this to discover what prompt templates a target MCP server provides.
Args:
target (string): Target MCP server - command or URL
transport ('stdio' | 'sse' | 'http'): Transport type
timeout_ms (number): Timeout in milliseconds (default: 60000)
Returns: JSON object with 'prompts' array containing prompt definitions.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target MCP server - either a command (e.g., 'node server.js') or URL (e.g., 'https://example.com/sse') | |
| transport | No | Transport type: 'stdio' for local commands, 'sse' for SSE URLs, 'http' for streamable HTTP | |
| timeout_ms | No | Timeout in milliseconds (default: 60000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds useful context about discovering prompt templates and the return format ('JSON object with prompts array'), but doesn't mention rate limits, authentication needs, or error behavior beyond the timeout parameter.
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 efficiently structured with a clear purpose statement, usage context, parameter listing, and return format - all in four concise sentences. Every sentence earns its place by providing distinct information without redundancy.
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 read-only list operation with comprehensive annotations and full schema coverage, the description provides adequate context. It explains the purpose, usage, parameters, and return format. The main gap is the lack of an output schema, but the description compensates by specifying the return structure. It could benefit from more behavioral details like error handling.
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?
With 100% schema description coverage, the input schema already fully documents all three parameters. The description's Args section repeats the parameter names and basic types but doesn't add meaningful semantic context beyond what's in the schema descriptions. The baseline of 3 is appropriate when 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 clearly states the specific action ('List all available prompts') and resource ('from a target MCP server'), distinguishing it from sibling tools like mcpdev_inspector_list_resources and mcpdev_inspector_list_tools. The second sentence further clarifies the purpose by explaining it's for discovering prompt templates.
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 clear context for when to use this tool ('to discover what prompt templates a target MCP server provides'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage for prompt discovery but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available resources from a target MCP server.
Use this to discover what resources (data/content) a target MCP server exposes.
Args:
target (string): Target MCP server - command or URL
transport ('stdio' | 'sse' | 'http'): Transport type
timeout_ms (number): Timeout in milliseconds (default: 60000)
Returns: JSON object with 'resources' array containing resource URIs and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target MCP server - either a command (e.g., 'node server.js') or URL (e.g., 'https://example.com/sse') | |
| transport | No | Transport type: 'stdio' for local commands, 'sse' for SSE URLs, 'http' for streamable HTTP | |
| timeout_ms | No | Timeout in milliseconds (default: 60000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies that this tool discovers resources from a target server, which clarifies the 'openWorldHint' annotation. While annotations cover safety (readOnly, non-destructive, idempotent), the description usefully explains the tool's exploratory purpose and return format, enhancing behavioral understanding without contradictions.
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 well-structured and appropriately sized, with a clear purpose statement followed by Args and Returns sections. It's front-loaded with the core functionality. However, the Args section could be more concise by relying on the schema, making it slightly 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 tool's complexity (list operation with server targeting), rich annotations (readOnly, openWorld, idempotent), and no output schema, the description is complete. It explains the purpose, parameters, and return format adequately, providing all necessary context for an agent to use it correctly without needing output schema 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?
With 100% schema description coverage, the schema already fully documents all parameters. The description's 'Args' section repeats schema information without adding significant meaning beyond it. This meets the baseline of 3, as the schema does the heavy lifting for 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 specific action ('List all available resources') and target ('from a target MCP server'), distinguishing it from sibling tools like list_tools or list_prompts. It explicitly mentions discovering what resources a server exposes, which is distinct from reading resources or calling tools.
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 clear context for when to use this tool ('to discover what resources a target MCP server exposes'), but it doesn't explicitly state when not to use it or name alternatives. It implies usage for resource discovery rather than tool or prompt listing, but lacks explicit exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available tools from a target MCP server.
Use this to discover what tools a target MCP server provides. Returns tool names, descriptions, and input schemas.
Args:
target (string): Target MCP server - command (e.g., 'node server.js') or URL
transport ('stdio' | 'sse' | 'http'): Transport type (auto-detected if not specified)
timeout_ms (number): Timeout in milliseconds (default: 60000)
Returns: JSON object with 'tools' array containing tool definitions.
Examples:
Local server: { target: "node dist/index.js", transport: "stdio" }
Remote SSE: { target: "https://mcp.example.com/sse", transport: "sse" }
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target MCP server - either a command (e.g., 'node server.js') or URL (e.g., 'https://example.com/sse') | |
| transport | No | Transport type: 'stdio' for local commands, 'sse' for SSE URLs, 'http' for streamable HTTP | |
| timeout_ms | No | Timeout in milliseconds (default: 60000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations by specifying what information is returned ('tool names, descriptions, and input schemas') and providing concrete examples of usage patterns. While annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description enhances understanding with practical implementation details without contradicting the annotations.
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 efficiently structured with a clear purpose statement, usage guidance, parameter overview, return specification, and practical examples - all in well-organized sections. Every sentence serves a distinct purpose with no redundancy or 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?
Given the tool's moderate complexity, comprehensive annotations (readOnlyHint, openWorldHint, idempotentHint), and complete schema documentation, the description provides all necessary context. It explains the tool's discovery purpose, distinguishes it from alternatives, and provides implementation examples, making it fully adequate despite the absence of an output schema.
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?
With 100% schema description coverage, the input schema already thoroughly documents all parameters. The description adds minimal value beyond the schema, providing only basic examples without additional semantic context. This meets the baseline expectation when schema coverage is complete.
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 with specific verb ('List') and resource ('all available tools from a target MCP server'). It distinguishes from siblings by focusing specifically on tools rather than prompts or resources, and explicitly mentions what information is returned (tool names, descriptions, and input schemas).
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 explicit guidance on when to use this tool ('Use this to discover what tools a target MCP server provides') and distinguishes it from sibling tools that handle different operations (calling tools, getting/listing prompts, listing/reading resources). The examples further clarify appropriate usage contexts for different server types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a specific resource from a target MCP server.
Use this to fetch the content of a resource by its URI.
Args:
target (string): Target MCP server - command or URL
transport ('stdio' | 'sse' | 'http'): Transport type
timeout_ms (number): Timeout in milliseconds (default: 60000)
uri (string): Resource URI to read
Returns: The resource content (text or base64-encoded blob).
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target MCP server - either a command (e.g., 'node server.js') or URL (e.g., 'https://example.com/sse') | |
| transport | No | Transport type: 'stdio' for local commands, 'sse' for SSE URLs, 'http' for streamable HTTP | |
| timeout_ms | No | Timeout in milliseconds (default: 60000) | |
| uri | Yes | Resource URI to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations by specifying that it returns 'text or base64-encoded blob' content, which helps the agent understand output format. However, it doesn't mention potential errors (e.g., if the URI doesn't exist) 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 well-structured with a clear purpose statement, usage note, and sections for Args and Returns. It's appropriately sized, but the Args section repeats schema details unnecessarily, slightly reducing efficiency. Every sentence adds value, such as clarifying the return format.
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 moderate complexity (4 parameters, no output schema), the description is mostly complete. It covers purpose, usage, parameters (via schema), and return format. However, it lacks details on error handling or edge cases (e.g., invalid URIs), which would be helpful for an agent. The annotations provide good safety context, compensating somewhat.
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 parameters. The description repeats some parameter info (e.g., 'target (string): Target MCP server - command or URL') but doesn't add significant meaning beyond what's in the schema. The baseline score of 3 is appropriate as 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 clearly states the specific action ('Read a specific resource') and resource ('from a target MCP server'), distinguishing it from sibling tools like list_resources (which lists rather than reads) and call_tool (which invokes tools rather than reading resources). The verb 'fetch the content' further clarifies the 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?
The description provides clear context for when to use this tool ('to fetch the content of a resource by its URI'), but it does not explicitly state when not to use it or name alternatives. For example, it doesn't contrast with list_resources (which might be used first to discover URIs) or get_prompt (which handles prompts rather than general resources).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: call_tool executes tools, get_prompt retrieves prompts, list_prompts lists prompts, list_resources lists resources, list_tools lists tools, and read_resource reads resources. The descriptions clearly differentiate their functions, making misselection unlikely.
All tools follow a consistent snake_case pattern with the prefix 'mcpdev_inspector_' followed by a verb_noun structure (e.g., call_tool, get_prompt, list_prompts). This predictability makes the tool set easy to navigate and understand.
With 6 tools, this server is well-scoped for its purpose of inspecting and interacting with MCP servers. Each tool serves a specific role in discovery and execution, with no redundancy, making the count appropriate and efficient.
The tool set provides complete coverage for the MCP server inspection domain, including listing tools, prompts, and resources, reading resources, getting prompts, and calling tools. There are no obvious gaps, enabling agents to perform all essential inspection and interaction tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Search, inspect and invoke every public tool on Invokera through one MCP connection.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kongyo2/mcpdevmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
