Skip to main content
Glama
r3-yamauchi

MCP Configuration Editor

by r3-yamauchi

validate_config

Check MCP configuration files for existence, JSON validity, and required server fields to identify issues before deployment.

Instructions

現在のMCP設定ファイルを検証する。

設定ファイルの存在、JSON形式の妥当性、各サーバー設定の
必須フィールドをチェックします。

Returns:
    Dict[str, Any]: 検証結果を含む辞書
        - valid: 検証が成功したかどうか
        - servers_count: サーバー数
        - servers: サーバー名のリスト
        - issues: 見つかった問題のリスト(ある場合)
        - error: エラーメッセージ(ある場合)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The handler function for the 'validate_config' tool. It checks if the config file exists, parses JSON, validates using Pydantic MCPConfig model, checks for issues like empty commands, and returns validation results including validity status, server count, list, and any issues or errors.
    @mcp.tool(name="validate_config")
    async def validate_config() -> Dict[str, Any]:
        """現在のMCP設定ファイルを検証する。
    
        設定ファイルの存在、JSON形式の妥当性、各サーバー設定の
        必須フィールドをチェックします。
    
        Returns:
            Dict[str, Any]: 検証結果を含む辞書
                - valid: 検証が成功したかどうか
                - servers_count: サーバー数
                - servers: サーバー名のリスト
                - issues: 見つかった問題のリスト(ある場合)
                - error: エラーメッセージ(ある場合)
        """
        if not CONFIG_PATH.exists():
            # 設定ファイルが存在しない場合
            return {
                "valid": False,
                "error": f"Configuration file not found at {CONFIG_PATH}",
                "hint": "Use add_server to create initial configuration",
            }
    
        try:
            # JSONファイルを読み込んでパース
            with open(CONFIG_PATH, "r") as f:
                data = json.load(f)
    
            # Pydanticモデルで検証
            config = MCPConfig(**data)
    
            # 各サーバー設定の検証
            issues = []
            for name, server in config.mcpServers.items():
                if not server.command:
                    issues.append(f"Server '{name}' has empty command")
    
            return {
                "valid": len(issues) == 0,
                "servers_count": len(config.mcpServers),
                "servers": list(config.mcpServers.keys()),
                "issues": issues if issues else None,
            }
    
        except json.JSONDecodeError as e:
            # JSONパースエラー
            return {"valid": False, "error": f"Invalid JSON: {str(e)}"}
        except Exception as e:
            # その他の検証エラー
            return {"valid": False, "error": f"Validation error: {str(e)}"}
  • Pydantic models (ServerConfig and MCPConfig) that define the schema for MCP server configurations. Used by the validate_config tool for input validation of the configuration file contents.
    class ServerConfig(BaseModel):
        """MCPサーバーの設定を表すモデル。
    
        Attributes:
            command: 実行するコマンド(例: "python", "uvx", "node")
            args: コマンドライン引数のリスト
            env: 環境変数の辞書(オプション)
        """
    
        command: str
        args: list[str] = Field(default_factory=list)
        env: Optional[Dict[str, str]] = None
    
    
    class MCPConfig(BaseModel):
        """mcp.json設定ファイルの構造を表すモデル。
    
        Attributes:
            mcpServers: サーバー名をキーとし、ServerConfigを値とする辞書
        """
    
        mcpServers: Dict[str, ServerConfig] = Field(default_factory=dict)
Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the tool's behavior by describing what it validates (file existence, JSON format, required fields) and the return structure. However, it doesn't mention error handling details, performance characteristics, or whether this is a read-only operation (though implied by validation).

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 perfectly structured and concise. It starts with the core purpose, details the validation scope in bullet-like clarity, and explicitly documents the return format. Every sentence adds value with zero redundancy or wasted words.

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

Completeness4/5

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

For a zero-parameter validation tool with no output schema, the description provides excellent context. It explains what gets validated and documents the return structure in detail. The only minor gap is lack of explicit mention about whether this is a read-only operation, though validation strongly implies it.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description correctly indicates no parameters are needed by not mentioning any, which aligns with the empty input schema. No additional parameter information is needed or provided.

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

Purpose5/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 specific verbs ('検証する' - validate) and resources ('現在のMCP設定ファイル' - current MCP configuration file). It distinguishes from siblings by focusing on validation rather than CRUD operations on servers (add_server, remove_server, etc.) or configuration export/retrieval.

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

Usage Guidelines4/5

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

The description implies usage context through its purpose - validating configuration files. However, it doesn't explicitly state when to use this tool versus alternatives like checking individual servers with get_server or listing servers with list_servers. The context is clear but lacks explicit exclusions or comparison to sibling tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/r3-yamauchi/mcp-conf-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server