Skip to main content
Glama
disler
by disler

Aider MCP Server - Experimental

Model context protocol server for offloading AI coding work to Aider, enhancing development efficiency and flexibility.

Overview

This server allows Claude Code to offload AI coding tasks to Aider, the best open source AI coding assistant. By delegating certain coding tasks to Aider, we can reduce costs, gain control over our coding model and operate Claude Code in a more orchestrative way to review and revise code.

Related MCP server: AiderMCP

Setup

  1. Clone the repository:

git clone https://github.com/disler/aider-mcp-server.git
  1. Install dependencies:

uv sync
  1. Create your environment file:

cp .env.sample .env
  1. Configure your API keys in the .env file (or use the mcpServers "env" section) to have the api key needed for the model you want to use in aider:

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
  1. Copy and fill out the the .mcp.json into the root of your project and update the --directory to point to this project's root directory and the --current-working-dir to point to the root of your project.

{
  "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
      }
    }
  }
}

Testing

Tests run with gemini-2.5-pro-exp-03-25

To run all tests:

uv run pytest

To run specific tests:

# 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

Note: The AI coding tests require a valid API key for the Gemini model. Make sure to set it in your .env file before running the tests.

Add this MCP server to Claude Code

Add with 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>"

Add with 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>"

Add with 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>"

Add with 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>"

Usage

This MCP server provides the following functionalities:

  1. Offload AI coding tasks to Aider:

    • Takes a prompt and file paths

    • Uses Aider to implement the requested changes

    • Returns success or failure

  2. List available models:

    • Provides a list of models matching a substring

    • Useful for discovering supported models

Available Tools

This MCP server exposes the following tools:

1. aider_ai_code

This tool allows you to run Aider to perform AI coding tasks based on a provided prompt and specified files.

Parameters:

  • ai_coding_prompt (string, required): The natural language instruction for the AI coding task.

  • relative_editable_files (list of strings, required): A list of file paths (relative to the current_working_dir) that Aider is allowed to modify. If a file doesn't exist, it will be created.

  • relative_readonly_files (list of strings, optional): A list of file paths (relative to the current_working_dir) that Aider can read for context but cannot modify. Defaults to an empty list [].

  • model (string, optional): The primary AI model Aider should use for generating code. Defaults to "gemini/gemini-2.5-pro-exp-03-25". You can use the list_models tool to find other available models.

  • editor_model (string, optional): The AI model Aider should use for editing/refining code, particularly when using architect mode. If not provided, the primary model might be used depending on Aider's internal logic. Defaults to None.

Example Usage (within an MCP request):

Claude Code Prompt:

Use the Aider AI Code tool to: Refactor the calculate_sum function in calculator.py to handle potential TypeError exceptions.

Result:

{
  "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"
  }
}

Returns:

  • A simple dict: {success, diff}

    • success: boolean - Whether the operation was successful.

    • diff: string - The diff of the changes made to the file.

2. list_models

This tool lists available AI models supported by Aider that match a given substring.

Parameters:

  • substring (string, required): The substring to search for within the names of available models.

Example Usage (within an MCP request):

Claude Code Prompt:

Use the Aider List Models tool to: List models that contain the substring "gemini".

Result:

{
  "name": "list_models",
  "parameters": {
    "substring": "gemini"
  }
}

Returns:

  • A list of model name strings that match the provided substring. Example: ["gemini/gemini-1.5-flash", "gemini/gemini-1.5-pro", "gemini/gemini-pro"]

Architecture

The server is structured as follows:

  • Server layer: Handles MCP protocol communication

  • Atoms layer: Individual, pure functional components

    • Tools: Specific capabilities (AI coding, listing models)

    • Utils: Constants and helper functions

    • Data Types: Type definitions using Pydantic

All components are thoroughly tested for reliability.

Codebase Structure

The project is organized into the following main directories and files:

.
├── 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 tool
  • src/aider_mcp_server: Contains the main application code.

    • atoms: Holds the fundamental building blocks. These are designed to be pure functions or simple classes with minimal dependencies.

      • tools: Each file here implements the core logic for a specific MCP tool (aider_ai_code, list_models).

      • utils.py: Contains shared constants like default model names.

      • data_types.py: Defines Pydantic models for request/response structures, ensuring data validation.

      • logging.py: Sets up a consistent logging format for console and file output.

    • server.py: Orchestrates the MCP server. It initializes the server, registers the tools defined in the atoms/tools directory, handles incoming requests, routes them to the appropriate tool logic, and sends back responses according to the MCP protocol.

    • __main__.py: Provides the command-line interface entry point (aider-mcp-server), parsing arguments like --editor-model and starting the server defined in server.py.

    • tests: Contains tests mirroring the structure of the src directory, ensuring that each component (especially atoms) works as expected.

Available Tools

2 tools
aider_ai_codeC

Run Aider to perform AI coding tasks based on the provided prompt and files

ParametersJSON Schema
NameRequiredDescriptionDefault
ai_coding_promptYesThe prompt for the AI to execute
relative_editable_filesYesLIST of relative paths to files that can be edited
relative_readonly_filesNoLIST of relative paths to files that can be read but not edited, add files that are not editable but useful for context
modelNoThe primary AI model Aider should use for generating code, leave blank unless model is specified in the request

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/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: '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.

Usage Guidelines2/5

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_modelsC

List available models that match the provided substring

ParametersJSON Schema
NameRequiredDescriptionDefault
substringNoSubstring to match against available models

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/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 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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observedaider_ai_code
    • First observedlist_models

TDQS

C2.9/5.0
Disambiguation5/5

The 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.

Naming Consistency3/5

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.

Tool Count2/5

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.

Completeness2/5

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.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude to delegate coding tasks to local Ollama models, reducing API token usage by up to 98.75% while leveraging local compute resources. Supports code generation, review, refactoring, and file analysis with Claude providing oversight and quality assurance.
    488
    24
    AGPL 3.0
  • F
    license
    B
    quality
    D
    maintenance
    Enables AI-powered code editing and development tasks through natural language conversations with Claude, using Aider's capabilities for improving code, adding features, fixing bugs, refactoring, and checking status.
    5
    1
    -
  • A
    license
    A
    quality
    C
    maintenance
    Enables Claude Code to offload routine code generation and text processing tasks to a local Ollama LLM, saving Cloud API tokens and costs with automatic model selection and security features.
    11
    77
    4
    Apache 2.0

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/disler/aider-mcp-server'

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