模型上下文协议服务器，用于将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-25claude 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-25claude 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-alphaclaude 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编码、列表模型）
Utils ：常量和辅助函数
数据类型：使用 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
