AI コーディング作業を Aider にオフロードし、開発の効率と柔軟性を向上させるモデル コンテキスト プロトコル サーバー。
このサーバーにより、Claude CodeはAIコーディングタスクを最高のオープンソースAIコーディングアシスタントであるAiderにオフロードできます。特定のコーディングタスクをAiderに委託することで、コストを削減し、コーディングモデルをコントロールし、Claude Codeをより効率的に運用してコードのレビューと修正を行うことができます。
Related MCP server: AiderMCP
リポジトリをクローンします。
git clone https://github.com/disler/aider-mcp-server.git依存関係をインストールします:
uv sync環境ファイルを作成します。
cp .env.sample .env.envファイルで API キーを構成して (または mcpServers の "env" セクションを使用して)、aider で使用するモデルに必要な API キーを取得します。
GEMINI_API_KEY=your_gemini_api_key_here
OPENAI_API_KEY=your_openai_api_key_here
ANTHROPIC_API_KEY=your_anthropic_api_key_here
...see .env.sample for more.mcp.jsonプロジェクトのルートにコピーして入力し、 --directoryがこのプロジェクトのルート ディレクトリを指すように更新し、 --current-working-dirプロジェクトのルートを指すように更新します。
{
"mcpServers": {
"aider-mcp-server": {
"type": "stdio",
"command": "uv",
"args": [
"--directory",
"<path to this project>",
"run",
"aider-mcp-server",
"--editor-model",
"gpt-4o",
"--current-working-dir",
"<path to your project>"
],
"env": {
"GEMINI_API_KEY": "<your gemini api key>",
"OPENAI_API_KEY": "<your openai api key>",
"ANTHROPIC_API_KEY": "<your anthropic api key>",
...see .env.sample for more
}
}
}
}gemini-2.5-pro-exp-03-25で実行されたテスト
すべてのテストを実行するには:
uv run pytest特定のテストを実行するには:
# Test listing models
uv run pytest src/aider_mcp_server/tests/atoms/tools/test_aider_list_models.py
# Test AI coding
uv run pytest src/aider_mcp_server/tests/atoms/tools/test_aider_ai_code.py注: AIコーディングテストには、Geminiモデルの有効なAPIキーが必要です。テストを実行する前に、 .envファイルに必ず設定してください。
gemini-2.5-pro-exp-03-25で追加claude mcp add aider-mcp-server -s local \
-- \
uv --directory "<path to the aider mcp server project>" \
run aider-mcp-server \
--editor-model "gemini/gemini-2.5-pro-exp-03-25" \
--current-working-dir "<path to your project>"gemini-2.5-pro-preview-03-25で追加claude mcp add aider-mcp-server -s local \
-- \
uv --directory "<path to the aider mcp server project>" \
run aider-mcp-server \
--editor-model "gemini/gemini-2.5-pro-preview-03-25" \
--current-working-dir "<path to your project>"quasar-alphaを追加claude mcp add aider-mcp-server -s local \
-- \
uv --directory "<path to the aider mcp server project>" \
run aider-mcp-server \
--editor-model "openrouter/openrouter/quasar-alpha" \
--current-working-dir "<path to your project>"llama4-maverick-instruct-basicで追加claude mcp add aider-mcp-server -s local \
-- \
uv --directory "<path to the aider mcp server project>" \
run aider-mcp-server \
--editor-model "fireworks_ai/accounts/fireworks/models/llama4-maverick-instruct-basic" \
--current-working-dir "<path to your project>"この MCP サーバーは次の機能を提供します。
AIコーディングタスクをAiderにオフロードします。
プロンプトとファイルパスを取得します
要求された変更を実装するためにAiderを使用する
成功または失敗を返します
利用可能なモデルの一覧:
部分文字列に一致するモデルのリストを提供します
サポートされているモデルを見つけるのに役立ちます
この MCP サーバーは次のツールを公開します。
aider_ai_codeこのツールを使用すると、Aider を実行して、提供されたプロンプトと指定されたファイルに基づいて AI コーディング タスクを実行できます。
パラメータ:
ai_coding_prompt (文字列、必須): AI コーディング タスクの自然言語の指示。
relative_editable_files (文字列のリスト、必須): Aider が変更できるファイルパスのリスト（ current_working_dirからの相対パス）。ファイルが存在しない場合は作成されます。
relative_readonly_files (文字列のリスト、オプション): Aiderがコンテキストとして読み取ることができるファイルパスのリスト（ current_working_dirからの相対パス）。デフォルトは空のリスト[]です。
model (文字列, オプション): Aiderがコード生成に使用する主要なAIモデル。デフォルトは"gemini/gemini-2.5-pro-exp-03-25"です。利用可能な他のモデルを見つけるには、 list_modelsツールを使用してください。
editor_model (文字列, オプション): Aiderがコードの編集/改良に使用するAIモデル。特にアーキテクトモード使用時に使用します。指定されていない場合は、Aiderの内部ロジックに応じてプライマリmodelが使用される場合があります。デフォルトはNoneです。
使用例 (MCP リクエスト内):
クロードコードプロンプト:
Use the Aider AI Code tool to: Refactor the calculate_sum function in calculator.py to handle potential TypeError exceptions.結果：
{
"name": "aider_ai_code",
"parameters": {
"ai_coding_prompt": "Refactor the calculate_sum function in calculator.py to handle potential TypeError exceptions.",
"relative_editable_files": ["src/calculator.py"],
"relative_readonly_files": ["docs/requirements.txt"],
"model": "openai/gpt-4o"
}
}戻り値:
単純な辞書: {success, diff}
success : boolean - 操作が成功したかどうか。
diff : 文字列 - ファイルに加えられた変更の差分。
list_modelsこのツールは、特定の部分文字列に一致する、Aider でサポートされている利用可能な AI モデルを一覧表示します。
パラメータ:
substring (文字列、必須): 使用可能なモデルの名前内で検索する部分文字列。
使用例 (MCP リクエスト内):
クロードコードプロンプト:
Use the Aider List Models tool to: List models that contain the substring "gemini".結果：
{
"name": "list_models",
"parameters": {
"substring": "gemini"
}
}戻り値:
指定された部分文字列に一致するモデル名文字列のリスト。例: ["gemini/gemini-1.5-flash", "gemini/gemini-1.5-pro", "gemini/gemini-pro"]
サーバーは次のように構成されています。
サーバー層: MCPプロトコル通信を処理する
原子層: 個々の純粋な機能コンポーネント
ツール: 特定の機能 (AI コーディング、モデルのリスト表示)
ユーティリティ: 定数とヘルパー関数
データ型: Pydantic を使用した型定義
すべてのコンポーネントは信頼性について徹底的にテストされています。
プロジェクトは、次の主要なディレクトリとファイルで構成されています。
.
├── ai_docs # Documentation related to AI models and examples
│ ├── just-prompt-example-mcp-server.xml
│ └── programmable-aider-documentation.md
├── pyproject.toml # Project metadata and dependencies
├── README.md # This file
├── specs # Specification documents
│ └── init-aider-mcp-exp.md
├── src # Source code directory
│ └── aider_mcp_server # Main package for the server
│ ├── __init__.py # Package initializer
│ ├── __main__.py # Main entry point for the server executable
│ ├── atoms # Core, reusable components (pure functions)
│ │ ├── __init__.py
│ │ ├── data_types.py # Pydantic models for data structures
│ │ ├── logging.py # Custom logging setup
│ │ ├── tools # Individual tool implementations
│ │ │ ├── __init__.py
│ │ │ ├── aider_ai_code.py # Logic for the aider_ai_code tool
│ │ │ └── aider_list_models.py # Logic for the list_models tool
│ │ └── utils.py # Utility functions and constants (like default models)
│ ├── server.py # MCP server logic, tool registration, request handling
│ └── tests # Unit and integration tests
│ ├── __init__.py
│ └── atoms # Tests for the atoms layer
│ ├── __init__.py
│ ├── test_logging.py # Tests for logging
│ └── tools # Tests for the tools
│ ├── __init__.py
│ ├── test_aider_ai_code.py # Tests for AI coding tool
│ └── test_aider_list_models.py # Tests for model listing toolsrc/aider_mcp_server : メインアプリケーションコードが含まれています。
atoms : 基本的な構成要素を保持します。これらは、依存関係が最小限の純粋関数または単純なクラスとして設計されています。
tools : ここでの各ファイルは、特定の MCP ツール ( aider_ai_code 、 list_models ) のコアロジックを実装します。
utils.py : デフォルトのモデル名などの共有定数が含まれています。
data_types.py : リクエスト/レスポンス構造の Pydantic モデルを定義し、データ検証を保証します。
logging.py : コンソールとファイル出力の一貫したログ形式を設定します。
server.py : MCPサーバーのオーケストレーションを行います。サーバーの初期化、 atoms/toolsディレクトリに定義されたツールの登録、受信したリクエストの処理、適切なツールロジックへのルーティング、MCPプロトコルに従ったレスポンスの返信を行います。
__main__.py : コマンドライン インターフェイスのエントリ ポイント ( aider-mcp-server ) を提供し、 --editor-modelなどの引数を解析し、 server.pyで定義されたサーバーを起動します。
tests : srcディレクトリの構造を反映したテストが含まれており、各コンポーネント (特にアトム) が期待どおりに動作することを確認します。
Run Aider to perform AI coding tasks based on the provided prompt and files
| Name | Required | Description | Default |
|---|---|---|---|
| ai_coding_prompt | Yes | The prompt for the AI to execute | |
| relative_editable_files | Yes | LIST of relative paths to files that can be edited | |
| relative_readonly_files | No | LIST of relative paths to files that can be read but not edited, add files that are not editable but useful for context | |
| model | No | The primary AI model Aider should use for generating code, leave blank unless model is specified in the request |
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. While 'Run Aider' implies execution and potential code modification, the description doesn't disclose critical behavioral traits: whether this tool makes permanent changes to files, what permissions are required, error handling, rate limits, or what happens when execution completes. For a tool that appears to modify code files, this is a significant gap.
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 extremely concise - a single sentence that efficiently communicates the core functionality. Every word earns its place with no redundancy or unnecessary elaboration. It's 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this appears to be a code execution/modification tool with no annotations, no output schema, and 4 parameters, the description is insufficiently complete. It doesn't explain what happens after execution, what the return values might be, error conditions, or safety considerations for a tool that presumably edits files. The single sentence description leaves too many important questions unanswered.
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 documents all 4 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. 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 tool's purpose: 'Run Aider to perform AI coding tasks based on the provided prompt and files'. It specifies the verb ('Run Aider') and resource ('AI coding tasks'), but doesn't differentiate from its only sibling 'list_models', which is a different type of tool. 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.
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, appropriate contexts, or exclusions. With a sibling tool 'list_models' available, there's no indication of when to choose one over the other or if they're complementary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available models that match the provided substring
| Name | Required | Description | Default |
|---|---|---|---|
| substring | No | Substring to match against available models |
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 mentions substring matching but fails to describe key behaviors like whether the list is paginated, if it includes metadata, what happens when no substring is provided, or any rate limits. This leaves significant gaps 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.
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 any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of model names, full details), behavioral traits like error handling, or usage context relative to the sibling tool. For a tool with no structured support, this leaves too many unknowns.
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?
The schema description coverage is 100%, with the parameter 'substring' fully documented in the schema. The description adds minimal value by implying substring matching but doesn't provide additional semantics beyond what the schema already states, such as case sensitivity or matching patterns.
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 a specific verb ('List') and resource ('available models'), and includes the filtering mechanism ('match the provided substring'). It distinguishes itself from a generic list operation by specifying substring matching, though it doesn't explicitly differentiate from the sibling tool 'aider_ai_code'.
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 no guidance on when to use this tool versus alternatives, such as the sibling 'aider_ai_code' or other potential model-related tools. It lacks context about prerequisites, exclusions, or specific scenarios where substring matching is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0aider_ai_codelist_modelsThe two tools have completely distinct purposes with no overlap: aider_ai_code performs AI coding tasks, while list_models provides information about available models. An agent can easily differentiate between them based on their clear, separate functions.
The naming shows mixed conventions: aider_ai_code uses a descriptive compound name with underscores, while list_models follows a more standard verb_noun pattern. They are both readable but lack a unified naming style, indicating some inconsistency in the tool set.
With only 2 tools, the server feels thin for an AI coding assistant domain. While aider_ai_code is a core tool, the lack of additional tools for tasks like file management, code review, or configuration limits the server's scope and utility, making the count too low for effective coverage.
The tool surface is severely incomplete for an AI coding assistant. It includes a primary coding tool and a model listing, but lacks essential operations such as file manipulation, code analysis, or session management. This creates significant gaps that will hinder agent workflows and lead to dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
One identity across Claude Code, Codex, Cursor, Gemini, Windsurf: shared inbox and handoffs.
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/disler/aider-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
