AI 코딩 작업을 Aider에 오프로드하여 개발 효율성과 유연성을 향상시키는 모델 컨텍스트 프로토콜 서버입니다.
이 서버를 통해 Claude Code는 AI 코딩 작업을 최고의 오픈소스 AI 코딩 어시스턴트인 Aider에 위임할 수 있습니다. 특정 코딩 작업을 Aider에 위임함으로써 비용을 절감하고, 코딩 모델을 제어하며, Claude Code를 더욱 체계적으로 운영하여 코드 검토 및 수정 작업을 수행할 수 있습니다.
Related MCP server: AiderMCP
저장소를 복제합니다.
지엑스피1
종속성 설치:
uv sync환경 파일을 만듭니다.
cp .env.sample .envAider에서 사용하려는 모델에 필요한 API 키를 갖도록 .env 파일에서 API 키를 구성하세요(또는 mcpServers "env" 섹션을 사용하세요):
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이 도구를 사용하면 제공된 프롬프트와 지정된 파일을 기반으로 AI 코딩 작업을 수행하기 위해 Aider를 실행할 수 있습니다.
매개변수:
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 디렉토리의 구조를 반영하는 테스트를 포함하고 있으며, 각 구성 요소(특히 Atom)가 예상대로 작동하는지 확인합니다.
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
