Skip to main content
Glama
r3-yamauchi

MCP Configuration Editor

by r3-yamauchi

add_server

Add a new MCP server configuration with name, command, and optional arguments or environment variables. Prevents duplicate server names by returning an error if the name already exists.

Instructions

新しいMCPサーバー設定を追加する。

既に同名のサーバーが存在する場合はエラーを返します。

Args:
    name: 新しいサーバーの名前
    command: 実行するコマンド
    args: コマンドライン引数(オプション)
    env: 環境変数(オプション)

Returns:
    Dict[str, Any]: 成功メッセージと追加されたサーバー情報、またはエラー情報

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
commandYes
argsNo
envNo

Implementation Reference

  • The core handler function for the 'add_server' tool. It registers the tool via @mcp.tool decorator, validates input, creates a new ServerConfig, adds it to the MCPConfig, saves to file, and returns success/error details.
    @mcp.tool(name="add_server")
    async def add_server(
        name: str, command: str, args: Optional[list[str]] = None, env: Optional[Dict[str, str]] = None
    ) -> Dict[str, Any]:
        """新しいMCPサーバー設定を追加する。
    
        既に同名のサーバーが存在する場合はエラーを返します。
    
        Args:
            name: 新しいサーバーの名前
            command: 実行するコマンド
            args: コマンドライン引数(オプション)
            env: 環境変数(オプション)
    
        Returns:
            Dict[str, Any]: 成功メッセージと追加されたサーバー情報、またはエラー情報
        """
        config = load_config()
    
        if name in config.mcpServers:
            # 同名のサーバーが既に存在する場合はエラーを返す
            logger.warning(f"Attempted to add duplicate server: {name}")
            return {
                "error": f"Server '{name}' already exists",
                "hint": "Use update_server to modify existing configuration",
            }
    
        # 新しいサーバー設定を作成
        server_config = ServerConfig(command=command, args=args or [], env=env)
    
        # 設定に追加して保存
        config.mcpServers[name] = server_config
    
        try:
            save_config(config)
            logger.info(f"Successfully added server: {name}")
            return {
                "message": f"Server '{name}' added successfully",
                "server": {
                    "name": name,
                    "command": server_config.command,
                    "args": server_config.args,
                    "env": server_config.env,
                },
            }
        except Exception as e:
            logger.error(f"Failed to save configuration after adding server {name}: {e}")
            return {"error": f"Failed to save configuration: {str(e)}", "hint": "Check file permissions and disk space"}
  • Pydantic schema/model for individual server configuration, directly instantiated in add_server handler with provided args.
    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
  • Pydantic schema/model for the overall MCP configuration file structure, loaded and modified in add_server.
    class MCPConfig(BaseModel):
        """mcp.json設定ファイルの構造を表すモデル。
    
        Attributes:
            mcpServers: サーバー名をキーとし、ServerConfigを値とする辞書
        """
    
        mcpServers: Dict[str, ServerConfig] = Field(default_factory=dict)
  • Helper function to persist the MCPConfig to JSON file, called by add_server after modification. Handles backups and atomic saves.
    def save_config(config: MCPConfig, create_backup_file: bool = True) -> None:
        """MCP設定をディスクに保存する。
    
        必要に応じて親ディレクトリを作成し、設定をJSON形式で保存します。
        Noneの値は除外され、読みやすいように2スペースでインデントされます。
    
        Args:
            config: 保存するMCP設定
            create_backup_file: 保存前にバックアップを作成するかどうか
    
        Raises:
            Exception: 保存に失敗した場合
        """
        try:
            # バックアップを作成
            if create_backup_file and CONFIG_PATH.exists():
                try:
                    create_backup()
                except Exception as e:
                    logger.warning(f"Failed to create backup, continuing with save: {e}")
    
            # 親ディレクトリが存在しない場合は作成
            CONFIG_PATH.parent.mkdir(parents=True, exist_ok=True)
    
            # 一時ファイルに書き込んでからアトミックに置き換え
            temp_path = CONFIG_PATH.with_suffix(".tmp")
            with open(temp_path, "w") as f:
                json.dump(config.model_dump(exclude_none=True), f, indent=2)
                f.write("\n")  # 最後に改行を追加
    
            # アトミックに置き換え
            temp_path.replace(CONFIG_PATH)
            logger.info(f"Configuration saved successfully to {CONFIG_PATH}")
        except Exception as e:
            logger.error(f"Failed to save configuration: {e}")
            raise
  • Helper function to load and parse the MCP config from file, called first in add_server.
    def load_config() -> MCPConfig:
        """現在のMCP設定を読み込む。
    
        設定ファイルが存在しない場合や読み込みエラーが発生した場合は、
        空の設定を返します。
    
        Returns:
            MCPConfig: 読み込まれた設定、またはデフォルトの空設定
        """
        if not CONFIG_PATH.exists():
            # 設定ファイルが存在しない場合は空の設定を返す
            logger.info(f"Configuration file not found at {CONFIG_PATH}")
            return MCPConfig()
    
        try:
            with open(CONFIG_PATH, "r") as f:
                data = json.load(f)
            config = MCPConfig(**data)
            logger.debug(f"Loaded configuration with {len(config.mcpServers)} servers")
            return config
        except json.JSONDecodeError as e:
            logger.error(f"Failed to parse JSON configuration: {e}")
            # エラーが発生した場合も空の設定を返す(既存の設定を破壊しない)
            return MCPConfig()
        except ValidationError as e:
            logger.error(f"Configuration validation failed: {e}")
            return MCPConfig()
        except Exception as e:
            logger.error(f"Unexpected error loading configuration: {e}")
            return MCPConfig()
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 key behavioral traits: the tool creates new configurations, returns error on duplicate names, and provides success/error responses. However, it doesn't mention permission requirements, side effects, rate limits, or whether the change is persistent/immediate. For a creation tool with zero annotation coverage, this is adequate but lacks comprehensive behavioral context.

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

Conciseness5/5

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

The description is perfectly structured and front-loaded: purpose statement first, then key behavioral constraint, followed by organized parameter and return value sections. Every sentence earns its place - the duplicate name warning is crucial, and the parameter documentation is essential given the schema coverage gap. No wasted words or redundancy.

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 creation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description does remarkably well. It covers purpose, key constraint, all parameters, and return value format. The main gap is lack of output schema, but the description partially compensates by mentioning the return type. Given the complexity, it's nearly complete but could benefit from more behavioral context about the creation process.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by providing clear parameter documentation in the Args section. It explains all 4 parameters (name, command, args, env), indicates which are optional, and gives meaningful Japanese descriptions that add semantic understanding beyond the bare schema. This is excellent parameter documentation given the schema coverage deficiency.

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 specific action ('新しいMCPサーバー設定を追加する' - adds new MCP server configuration) and resource (server settings). It distinguishes from siblings by focusing on creation rather than retrieval (get_server, list_servers), modification (update_server), or deletion (remove_server). The purpose is unambiguous and well-defined.

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 provides clear context about when NOT to use this tool ('既に同名のサーバーが存在する場合はエラーを返します' - returns error if server with same name exists), which helps avoid duplicate creation attempts. However, it doesn't explicitly mention when to use alternatives like update_server for modifying existing servers or compare with other siblings, leaving some guidance gaps.

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