Skip to main content
Glama
Serena MCP Server

Serena MCP Server

by lin2000wl
  • :rocket: Serena is a powerful coding agent toolkit capable of turning an LLM into a fully-featured agent that works directly on your codebase.

  • :wrench: Serena provides essential semantic code retrieval and editing tools that are akin to an IDE's capabilities, extracting code entities at the symbol level and exploiting relational structure.

  • :free: Serena is free & open-source, enhancing the capabilities of LLMs you already have access to free of charge.

Demonstration

Here is a demonstration of Serena implementing a small feature for itself (a better log GUI) with Claude Desktop. Note how Serena's tools enable Claude to find and edit the right symbols.

https://github.com/user-attachments/assets/6eaa9aa1-610d-4723-a2d6-bf1e487ba753

LLM Integration

Serena provides the necessary tools for coding workflows, but an LLM is required to do the actual work, orchestrating tool use.

For example, supercharge the performance of Claude Code with a one-line shell command.

Serena can be integrated with an LLM in several ways:

  • by using the model context protocol (MCP).
    Serena provides an MCP server which integrates with

    • Claude Code and Claude Desktop,

    • IDEs like VSCode, Cursor or IntelliJ,

    • Extensions like Cline or Roo Code

    • and many others, including the ChatGPT app soon

  • by using Agno – the model-agnostic agent framework.
    Serena's Agno-based agent allows you to turn virtually any LLM into a coding agent, whether it's provided by Google, OpenAI or Anthropic (with a paid API key) or a free model provided by Ollama, Together or Anyscale.

  • by incorporating Serena's tools into an agent framework of your choice.
    Serena's tool implementation is decoupled from the framework-specific code and can thus easily be adapted to any agent framework.

Programming Language Support & Semantic Analysis Capabilities

Serena's semantic code analysis capabilities build on language servers using the widely implemented language server protocol (LSP). The LSP provides a set of versatile code querying and editing functionalities based on symbolic understanding of the code. Equipped with these capabilities, Serena discovers and edits code just like a seasoned developer making use of an IDE's capabilities would. Serena can efficiently find the right context and do the right thing even in very large and complex projects! So not only is it free and open-source, it frequently achieves better results than existing solutions that charge a premium.

Language servers provide support for a wide range of programming languages. With Serena, we provide

  • direct, out-of-the-box support for:

    • Python

    • TypeScript/Javascript (currently has some instability issues, we are working on it)

    • PHP

    • Go (need to install go and gopls first)

    • Rust

    • C# (requires dotnet to be installed. We switched the underlying language server recently, please report any issues you encounter)

    • Java (Note: startup is slow, initial startup especially so. There may be issues with java on macos and linux, we are working on it.)

    • Clojure

    • C/C++ (You may experience issues with finding references, we are working on it)

  • indirect support (may require some code changes/manual installation) for:

    • Ruby (untested)

    • Kotlin (untested)

    • Dart (untested)

    These languages are supported by the language server library, but we did not explicitly test whether the support for these languages actually works flawlessly.

Further languages can, in principle, easily be supported by providing a shallow adapter for a new language server implementation.

Table of Contents

Related MCP server: Files-DB-MCP

What Can I Use Serena For?

You can use Serena for any coding tasks – whether it is focussed on analysis, planning, designing new components or refactoring existing ones. Since Serena's tools allow an LLM to close the cognitive perception-action loop, agents based on Serena can autonomously carry out coding tasks from start to finish – from the initial analysis to the implementation, testing and, finally, the version control system commit.

Serena can read, write and execute code, read logs and the terminal output. While we do not necessarily encourage it, "vibe coding" is certainly possible, and if you want to almost feel like "the code no longer exists", you may find Serena even more adequate for vibing than an agent inside an IDE (since you will have a separate GUI that really lets you forget).

Free Coding Agents with Serena

Even the free tier of Anthropic's Claude has support for MCP Servers, so you can use Serena with Claude for free. Presumably, the same will soon be possible with ChatGPT Desktop once support for MCP servers is added.
Through Agno, you furthermore have the option to use Serena with a free/open-weights model.

Serena is Oraios AI's contribution to the developer community.
We use it ourselves on a regular basis.

We got tired of having to pay multiple IDE-based subscriptions (such as Windsurf or Cursor) that forced us to keep purchasing tokens on top of the chat subscription costs we already had. The substantial API costs incurred by tools like Claude Code, Cline, Aider and other API-based tools are similarly unattractive. We thus built Serena with the prospect of being able to cancel most other subscriptions.

Quick Start

Serena can be used in various ways, below you will find instructions for selected integrations.

  • If you just want to turn Claude into a free-to-use coding agent, we recommend using Serena through Claude Code or Claude Desktop.

  • If you want to use Gemini or any other model, and you want a GUI experience, you can use Agno or one of the many other GUIs that support MCP servers.

  • If you want to use Serena integrated in your IDE, see the section on other MCP clients or the dedicated Cursor deployment guide.

Serena is managed by uv, so you will need to install it).

Running the Serena MCP Server

You have several options for running the MCP server, which are explained in the subsections below.

Usage

The typical usage involves the client (Claude Code, Claude Desktop, etc.) running the MCP server as a subprocess (using stdio communication), so the client needs to be provided with the command to run the MCP server. (Alternatively, you can run the MCP server in SSE mode and tell your client how to connect to it.)

Note that no matter how you run the MCP server, Serena will, by default, start a small web-based dashboard on localhost that will display logs and allow shutting down the MCP server (since many clients fail to clean up processes correctly). This and other settings can be adjusted in the configuration and/or by providing command-line arguments.

Local Installation
  1. Clone the repository and change into it.

    git clone https://github.com/oraios/serena
    cd serena
  2. Optionally create a config file from the template and adjust it according to your preferences.

    cp src/serena/resources/serena_config.template.yml serena_config.yml

    If you just want the default config, you can skip this part, and a config file will be created when you first run Serena.

  3. Run the server with uv:

    uv run serena-mcp-server

    When running from outside the serena installation directory, be sure to pass it, i.e. use

     uv run --directory /abs/path/to/serena serena-mcp-server
Using uvx

uvx can be used to run the latest version of Serena directly from the repository, without an explicit local installation.

  • Windows:

    uvx --from git+https://github.com/oraios/serena serena-mcp-server.exe
  • Other operating systems:

    uvx --from git+https://github.com/oraios/serena serena-mcp-server
Using Docker (Experimental)

⚠️ Docker support is currently experimental with several limitations. Please read the Docker documentation for important caveats before using it.

You can run the Serena MCP server directly via docker as follows, assuming that the projects you want to work on are all located in /path/to/your/projects:

docker run --rm -i --network host -v /path/to/your/projects:/workspaces/projects ghcr.io/oraios/serena:latest serena-mcp-server --transport stdio

Replace /path/to/your/projects with the absolute path to your projects directory. The Docker approach provides:

  • Better security isolation for shell command execution

  • No need to install language servers and dependencies locally

  • Consistent environment across different systems

See the Docker documentation for detailed setup instructions, configuration options, and known limitations.

SSE Mode

ℹ️ Note that MCP servers which use stdio as a protocol are somewhat unusual as far as client/server architectures go, as the server necessarily has to be started by the client in order for communication to take place via the server's standard input/output stream. In other words, you do not need to start the server yourself. The client application (e.g. Claude Desktop) takes care of this and therefore needs to be configured with a launch command.

When using instead the SSE mode, which uses HTTP-based communication, you control the server lifecycle yourself, i.e. you start the server and provide the client with the URL to connect to it.

Simply provide serena-mcp-server with the --transport sse option and optionally provide the port. For example, to run the Serena MCP server in SSE mode on port 9121 using a local installation, you would run this command from the Serena directory,

uv run serena-mcp-server --transport sse --port 9121

and then configure your client to connect to http://localhost/sse:9121.

Command-Line Arguments

The Serena MCP server supports a wide range of additional command-line options, including the option to run in SSE mode and to adapt Serena to various contexts and modes of operation.

Run with parameter --help to get a list of available options.

Configuration

Serena's behavior (active tools and prompts as well as logging configuration, etc.) is configured in four places:

  1. The serena_config.yml for general settings that apply to all clients and projects

  2. In the arguments passed to the serena-mcp-server in your client's config (see below), which will apply to all sessions started by the respective client. In particular, the context parameter should be set appropriately for Serena to be best adjusted to existing tools and capabilities of your client. See for a detailed explanation. You can override all entries from the serena_config.yml through command line arguments.

  3. In the .serena/project.yml file within your project. This will hold project-level configuration that is used whenever that project is activated.

  4. Through the currently active set of modes.

⚠️ Note: Serena is under active development. We are continuously adding features, improving stability and the UX. As a result, configuration may change in a breaking manner. If you have an invalid configuration, the MCP server or Serena-based Agent may fail to start (investigate the MCP logs in the former case). Check the changelog and the configuration templates when updating Serena, adapting your configurations accordingly.

After the initial setup, continue with one of the sections below, depending on how you want to use Serena.

You can just ask the LLM to show you the config of your session, Serena has a tool for it.

Project Activation & Indexing

The recommended way is to just ask the LLM to activate a project by providing it an absolute path to, or, in case the project was activated in the past, by its name. The default project name is the directory name.

  • "Activate the project /path/to/my_project"

  • "Activate the project my_project"

All projects that have been activated will be automatically added to your serena_config.yml, and for each project, the file .serena/project.yml will be generated. You can adjust the latter, e.g., by changing the name (which you refer to during the activation) or other options. Make sure to not have two different projects with the same name.

If you are mostly working with the same project, you can also configure to always activate a project at startup by passing --project <path_or_name> to the serena-mcp-server command in your client's MCP config.

ℹ️ For larger projects, we recommend that you index your project to accelerate Serena's tools; otherwise the first tool application may be very slow. To do so, run one of these commands the project directory or pass the path to the project as an argument:

  • When using a local installation:

    uv run --directory /abs/path/to/serena index-project
  • When using uvx:

    uvx --from git+https://github.com/oraios/serena index-project

Claude Code

Serena is a great way to make Claude Code both cheaper and more powerful!

From your project directory, add serena with a command like this,

claude mcp add serena -- <serena-mcp-server> --context ide-assistant --project $(pwd)

where <serena-mcp-server> is your way of running the Serena MCP server. For example, when using uvx, you would run

claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena-mcp-server --context ide-assistant --project $(pwd)

ℹ️ Once in Claude Code, you should ask Claude to "Read the initial instructions" as your first prompt, such that it will receive information on how to use Serena's tools.

Claude Desktop

For Claude Desktop (available for Windows and macOS), go to File / Settings / Developer / MCP Servers / Edit Config, which will let you open the JSON file claude_desktop_config.json. Add the serena MCP server configuration, using a run command depending on your setup.

  • local installation:

    {
        "mcpServers": {
            "serena": {
                "command": "/abs/path/to/uv",
                "args": ["run", "--directory", "/abs/path/to/serena", "serena-mcp-server"]
            }
        }
    }
  • uvx:

    {
        "mcpServers": {
            "serena": {
                "command": "/abs/path/to/uvx",
                "args": ["--from", "git+https://github.com/oraios/serena", "serena-mcp-server"]
            }
        }
    }
  • docker:

     {
         "mcpServers": {
             "serena": {
                 "command": "docker",
                 "args": ["run", "--rm", "-i", "--network", "host", "-v", "/path/to/your/projects:/workspaces/projects", "ghcr.io/oraios/serena:latest", "serena-mcp-server", "--transport", "stdio"]
             }
         }
     }

If you are using paths containing backslashes for paths on Windows (note that you can also just use forward slashes), be sure to escape them correctly (\\).

That's it! Save the config and then restart Claude Desktop. You are ready for activating your first project.

ℹ️ You can further customize the run command using additional arguments (see above).

Note: on Windows and macOS there are official Claude Desktop applications by Anthropic, for Linux there is an open-source community version.

⚠️ Be sure to fully quit the Claude Desktop application, as closing Claude will just minimize it to the system tray – at least on Windows.

⚠️ Some clients, currently including Claude Desktop, may leave behind zombie processes. You will have to find and terminate them manually then. With Serena, you can activate the dashboard to prevent unnoted processes and also use the dashboard for shutting down Serena.

After restarting, you should see Serena's tools in your chat interface (notice the small hammer icon).

For more information on MCP servers with Claude Desktop, see the official quick start guide.

Other MCP Clients (Cline, Roo-Code, Cursor, Windsurf, etc.)

Being an MCP Server, Serena can be included in any MCP Client. The same configuration as above, perhaps with small client-specific modifications, should work. Most of the popular existing coding assistants (IDE extensions or VSCode-like IDEs) support connections to MCP Servers. It is recommended to use the ide-assistant context for these integrations by adding "--context", "ide-assistant" to the args in your MCP client's configuration. Including Serena generally boosts their performance by providing them tools for symbolic operations.

In this case, the billing for the usage continues to be controlled by the client of your choice (unlike with the Claude Desktop client). But you may still want to use Serena through such an approach, e.g., for one of the following reasons:

  1. You are already using a coding assistant (say Cline or Cursor) and just want to make it more powerful.

  2. You are on Linux and don't want to use the community-created Claude Desktop.

  3. You want tighter integration of Serena into your IDE and don't mind paying for that.

Cursor全局MCP部署指南

Cursor 是一个基于VS Code的AI编程IDE,支持全局MCP服务器配置。以下是将Serena部署为Cursor全局MCP服务器的详细步骤:

前置要求

在开始配置之前,请确保安装TypeScript语言服务器以解决中文兼容性问题:

npm install -g typescript-language-server typescript

这个安装步骤非常重要,因为它能够解决Serena在处理包含中文字符的项目时可能遇到的兼容性问题。

配置步骤

  1. 打开Cursor设置

    • 在Cursor中按 Ctrl+Shift+P (Windows/Linux) 或 Cmd+Shift+P (macOS)

    • 输入并选择 "Preferences: Open Settings (JSON)"

  2. 添加MCP服务器配置

    在settings.json文件中添加以下配置:

    本地安装方式:

    {
      "mcp.servers": {
        "serena": {
          "command": "/absolute/path/to/uv",
          "args": [
            "run", 
            "--directory", 
            "/absolute/path/to/serena", 
            "serena-mcp-server",
            "--context",
            "ide-assistant"
          ],
          "env": {}
        }
      }
    }

    使用Python+uv方式(推荐):

{
  "mcp.servers": {
    "serena": {
      "command": "py",
      "args": [
        "-3.11", "-m", "uv", "run",
        "--directory", "H:\AI\Serena\serena-main",
        "serena-mcp-server",
        "--context", "ide-assistant",
        "--mode", "interactive",
        "--mode", "editing"
      ],
      "env": {
        "UV_INDEX_URL": "https://mirrors.aliyun.com/pypi/simple/"
      }
    }
  }
}

这种方式的优势:

  • 使用指定的Python版本(3.11)

  • 通过阿里云镜像加速包安装

  • 配置简单,无需绝对路径到uv

  • 同时启用交互和编辑模式

  • 适合中国用户的网络环境

使用uvx方式:

{
  "mcp.servers": {
    "serena": {
      "command": "/absolute/path/to/uvx",
      "args": [
        "--from", 
        "git+https://github.com/oraios/serena", 
        "serena-mcp-server",
        "--context",
        "ide-assistant"
      ],
      "env": {}
    }
  }
}

Docker方式:

{
  "mcp.servers": {
    "serena": {
      "command": "docker",
      "args": [
        "run", 
        "--rm", 
        "-i", 
        "--network", 
        "host", 
        "-v", 
        "/path/to/your/projects:/workspaces/projects", 
        "ghcr.io/oraios/serena:latest", 
        "serena-mcp-server", 
        "--transport", 
        "stdio",
        "--context",
        "ide-assistant"
      ],
      "env": {}
    }
  }
}
  1. Windows路径注意事项

    在Windows系统上,请确保正确转义路径中的反斜杠:

    {
      "mcp.servers": {
        "serena": {
          "command": "C:\Users\YourName\AppData\Local\Programs\uv\uv.exe",
          "args": [
            "run", 
            "--directory", 
            "C:\path\to\serena", 
            "serena-mcp-server",
            "--context",
            "ide-assistant"
          ]
        }
      }
    }
  2. 保存并重启Cursor

    保存settings.json文件后,重启Cursor以使配置生效。

验证安装

  1. 重启Cursor后,打开任意项目

  2. 在聊天界面中,您应该能看到Serena的工具(通常显示为小锤子图标)

  3. 发送消息 "Read the initial instructions" 来获取Serena的使用指南

  4. 使用 "Activate the project /path/to/your/project" 来激活项目

中文兼容性优化

通过预先安装TypeScript语言服务器,Serena能够更好地处理:

  • 包含中文注释的代码文件

  • 中文文件名和目录名

  • 中文字符串常量

  • 混合中英文的项目结构

故障排除

如果遇到问题,请检查:

  1. 路径正确性:确保所有路径都是绝对路径

  2. 权限问题:确保Cursor有权限执行指定的命令

  3. 依赖安装:验证uv、uvx或Docker是否正确安装

  4. TypeScript语言服务器:确认已全局安装typescript-language-server

  5. 日志查看:查看Cursor的开发者控制台以获取详细错误信息

高级配置选项

您可以通过添加更多参数来自定义Serena的行为:

{
  "mcp.servers": {
    "serena": {
      "command": "py",
      "args": [
        "-3.11", "-m", "uv", "run",
        "--directory", "H:\AI\Serena\serena-main",
        "serena-mcp-server",
        "--context", "ide-assistant",
        "--mode", "editing",
        "--mode", "interactive",
        "--project", "/default/project/path"
      ],
      "env": {
        "UV_INDEX_URL": "https://mirrors.aliyun.com/pypi/simple/",
        "SERENA_LOG_LEVEL": "INFO"
      }
    }
  }
}

通过这种配置,Serena将作为全局MCP服务器在Cursor中运行,为您的所有项目提供强大的AI辅助编程能力。

Agno Agent

Agno is a model-agnostic agent framework that allows you to turn Serena into an agent (independent of the MCP technology) with a large number of underlying LLMs. Agno is currently the simplest way of running Serena in a chat GUI with an LLM of your choice.

While Agno is not yet entirely stable, we chose it, because it comes with its own open-source UI, making it easy to directly use the agent using a chat interface. With Agno, Serena is turned into an agent (so no longer an MCP Server), so it can be used in programmatic ways (for example for benchmarking or within your application).

Here's how it works (see also Agno's documentation):

  1. Download the agent-ui code with npx

    npx create-agent-ui@latest

    or, alternatively, clone it manually:

    git clone https://github.com/agno-agi/agent-ui.git
    cd agent-ui 
    pnpm install 
    pnpm dev
  2. Install serena with the optional requirements:

    # You can also only select agno,google or agno,anthropic instead of all-extras
    uv pip install --all-extras -r pyproject.toml -e .
  3. Copy .env.example to .env and fill in the API keys for the provider(s) you intend to use.

  4. Start the agno agent app with

    uv run python scripts/agno_agent.py

    By default, the script uses Claude as the model, but you can choose any model supported by Agno (which is essentially any existing model).

  5. In a new terminal, start the agno UI with

    cd agent-ui 
    pnpm dev

    Connect the UI to the agent you started above and start chatting. You will have the same tools as in the MCP server version.

Here is a short demo of Serena performing a small analysis task with the newest Gemini model:

https://github.com/user-attachments/assets/ccfcb968-277d-4ca9-af7f-b84578858c62

⚠️ IMPORTANT: In contrast to the MCP server approach, tool execution in the Agno UI does not ask for the user's permission. The shell tool is particularly critical, as it can perform arbitrary code execution. While we have never encountered any issues with this in our testing with Claude, allowing this may not be entirely safe. You may choose to disable certain tools for your setup in your Serena project's configuration file (.yml).

Other Agent Frameworks

It should be straightforward to incorporate Serena into any agent framework (like pydantic-ai, langgraph or others). Typically, you need only to write an adapter for Serena's tools to the tool representation in the framework of your choice, as was done by us for Agno with SerenaAgnoToolkit.

Detailed Usage and Recommendations

Tool Execution

Serena combines tools for semantic code retrieval with editing capabilities and shell execution. Serena's behavior can be further customized through Modes and Contexts. Find the complete list of tools below.

The use of all tools is generally recommended, as this allows Serena to provide the most value: Only by executing shell commands (in particular, tests) can Serena identify and correct mistakes autonomously.

Shell Execution and Editing Tools

However, it should be noted that the execute_shell_command tool allows for arbitrary code execution. When using Serena as an MCP Server, clients will typically ask the user for permission before executing a tool, so as long as the user inspects execution parameters beforehand, this should not be a problem. However, if you have concerns, you can choose to disable certain commands in your project's .yml configuration file. If you only want to use Serena purely for analyzing code and suggesting implementations without modifying the codebase, you can enable read-only mode by setting read_only: true in your project configuration file. This will automatically disable all editing tools and prevent any modifications to your codebase while still allowing all analysis and exploration capabilities.

In general, be sure to back up your work and use a version control system in order to avoid losing any work.

Modes and Contexts

Serena's behavior and toolset can be adjusted using contexts and modes. These allow for a high degree of customization to best suit your workflow and the environment Serena is operating in.

Contexts

A context defines the general environment in which Serena is operating. It influences the initial system prompt and the set of available tools. A context is set at startup when launching Serena (e.g., via CLI options for an MCP server or in the agent script) and cannot be changed during an active session.

Serena comes with pre-defined contexts:

  • desktop-app: Tailored for use with desktop applications like Claude Desktop. This is the default.

  • agent: Designed for scenarios where Serena acts as a more autonomous agent, for example, when used with Agno.

  • ide-assistant: Optimized for integration into IDEs like VSCode, Cursor, or Cline, focusing on in-editor coding assistance. Choose the context that best matches the type of integration you are using.

When launching Serena, specify the context using --context <context-name>.
Note that for cases where parameter lists are specified (e.g. Claude Desktop), you must add two parameters to the list.

Modes

Modes further refine Serena's behavior for specific types of tasks or interaction styles. Multiple modes can be active simultaneously, allowing you to combine their effects. Modes influence the system prompt and can also alter the set of available tools by excluding certain ones.

Examples of built-in modes include:

  • planning: Focuses Serena on planning and analysis tasks.

  • editing: Optimizes Serena for direct code modification tasks.

  • interactive: Suitable for a conversational, back-and-forth interaction style.

  • one-shot: Configures Serena for tasks that should be completed in a single response, often used with planning for generating reports or initial plans.

  • no-onboarding: Skips the initial onboarding process if it's not needed for a particular session.

  • onboarding: (Usually triggered automatically) Focuses on the project onboarding process.

Modes can be set at startup (similar to contexts) but can also be switched dynamically during a session. You can instruct the LLM to use the switch_modes tool to activate a different set of modes (e.g., "switch to planning and one-shot modes").

When launching Serena, specify modes using --mode <mode-name>; multiple modes can be specified, e.g. --mode planning --mode no-onboarding.

:warning: Mode Compatibility: While you can combine modes, some may be semantically incompatible (e.g., interactive and one-shot). Serena currently does not prevent incompatible combinations; it is up to the user to choose sensible mode configurations.

Customization

You can create your own contexts and modes to precisely tailor Serena to your needs in two ways:

  • Adding to Serena's configuration directory: Create new .yml files in the config/contexts/ or config/modes/ directories within your local Serena repository. These custom contexts/modes will be automatically registered and available for use by their name (filename without the .yml extension). They will also appear in listings of available contexts/modes.

  • Using external YAML files: When starting Serena, you can provide an absolute path to a custom .yml file for a context or mode.

A context or mode YAML file typically defines:

  • name: (Optional if filename is used) The name of the context/mode.

  • prompt: A string that will be incorporated into Serena's system prompt.

  • description: (Optional) A brief description.

  • excluded_tools: A list of tool names (strings) to disable when this context/mode is active.

This customization allows for deep integration and adaptation of Serena to specific project requirements or personal preferences.

Onboarding and Memories

By default, Serena will perform an onboarding process when it is started for the first time for a project. The goal of the onboarding is for Serena to get familiar with the project and to store memories, which it can then draw upon in future interactions. If an LLM should fail to complete the onboarding and does not actually write the respective memories to disk, you may need to ask it to do so explicitly.

The onboarding will usually read a lot of content from the project, thus filling up the context. It can therefore be advisable to switch to another conversation once the onboarding is complete. After the onboarding, we recommend that you have a quick look at the memories and, if necessary, edit them or add additional ones.

Memories are files stored in .serena/memories/ in the project directory, which the agent can choose to read in subsequent interactions. Feel free to read and adjust them as needed; you can also add new ones manually. Every file in the .serena/memories/ directory is a memory file. Whenever Serena starts working on a project, the list of memories is provided, and the agent can decide to read them. We found that memories can significantly improve the user experience with Serena.

Prepare Your Project

Structure Your Codebase

Serena uses the code structure for finding, reading and editing code. This means that it will work well with well-structured code but may perform poorly on fully unstructured one (like a "God class" with enormous, non-modular functions).
Furthermore, for languages that are not statically typed, type annotations are highly beneficial.

Start from a Clean State

It is best to start a code generation task from a clean git state. Not only will this make it easier for you to inspect the changes, but also the model itself will have a chance of seeing what it has changed by calling git diff and thereby correct itself or continue working in a followup conversation if needed.

:warning: Important: since Serena will write to files using the system-native line endings and it might want to look at the git diff, it is important to set git config core.autocrlf to true on Windows. With git config core.autocrlf set to false on Windows, you may end up with huge diffs only due to line endings. It is generally a good idea to globally enable this git setting on Windows:

git config --global core.autocrlf true

Logging, Linting, and Automated Tests

Serena can successfully complete tasks in an agent loop, where it iteratively acquires information, performs actions, and reflects on the results. However, Serena cannot use a debugger; it must rely on the results of program executions, linting results, and test results to assess the correctness of its actions. Therefore, software that is designed to meaningful interpretable outputs (e.g. log messages) and that has a good test coverage is much easier to work with for Serena.

We generally recommend to start an editing task from a state where all linting checks and tests pass.

Prompting Strategies

We found that it is often a good idea to spend some time conceptualizing and planning a task before actually implementing it, especially for non-trivial task. This helps both in achieving better results and in increasing the feeling of control and staying in the loop. You can make a detailed plan in one session, where Serena may read a lot of your code to build up the context, and then continue with the implementation in another (potentially after creating suitable memories).

Potential Issues in Code Editing

In our experience, LLMs are bad at counting, i.e. they have problems inserting blocks of code in the right place. Most editing operations can be performed at the symbolic level, allowing this problem is overcome. However, sometimes, line-level insertions are useful.

Serena is instructed to double-check the line numbers and any code blocks that it will edit, but you may find it useful to explicitly tell it how to edit code if you run into problems.
We are working on making Serena's editing capabilities more robust.

Running Out of Context

For long and complicated tasks, or tasks where Serena has read a lot of content, you may come close to the limits of context tokens. In that case, it is often a good idea to continue in a new conversation. Serena has a dedicated tool to create a summary of the current state of the progress and all relevant info for continuing it. You can request to create this summary and write it to a memory. Then, in a new conversation, you can just ask Serena to read the memory and continue with the task. In our experience, this worked really well. On the up-side, since in a single session there is no summarization involved, Serena does not usually get lost (unlike some other agents that summarize under the hood), and it is also instructed to occasionally check whether it's on the right track.

Moreover, Serena is instructed to be frugal with context (e.g., to not read bodies of code symbols unnecessarily), but we found that Claude is not always very good in being frugal (Gemini seemed better at it). You can explicitly instruct it to not read the bodies if you know that it's not needed.

Combining Serena with Other MCP Servers

When using Serena through an MCP Client, you can use it together with other MCP servers. However, beware of tool name collisions! See info on that above.

Currently, there is a collision with the popular Filesystem MCP Server. Since Serena also provides filesystem operations, there is likely no need to ever enable these two simultaneously.

Serena's Logs: The Dashboard and GUI Tool

Serena provides two convenient ways of accessing the logs of the current session:

  • via the web-based dashboard (enabled by default)

    This is supported on all platforms. By default, it will be accessible at http://localhost:24282/dashboard/index.html, but a higher port may be used if the default port is unavailable/multiple instances are running.

  • via the GUI tool (disabled by default)

    This is mainly supported on Windows, but it may also work on Linux; macOS is unsupported.

Both can be enabled or disabled in Serena's configuration file (serena_config.yml, see above). If enabled, they will automatically be opened as soon as the Serena agent/MCP server is started.

In addition to viewing logs, both tools allow to shut down the Serena agent. This function is provided, because clients like Claude Desktop may fail to terminate the MCP server subprocess when they themselves are closed.

Troubleshooting

Support for MCP Servers in Claude Desktop and the various MCP Server SDKs are relatively new developments and may display instabilities.

The working configuration of an MCP server may vary from platform to platform and from client to client. We recommend always using absolute paths, as relative paths may be sources of errors. The language server is running in a separate sub-process and is called with asyncio – sometimes a client may make it crash. If you have Serena's log window enabled, and it disappears, you'll know what happened.

Some clients may not properly terminate MCP servers, look out for hanging python processes and terminate them manually, if needed.

Comparison with Other Coding Agents

To our knowledge, Serena is the first fully-featured coding agent where the entire functionality is available through an MCP server, thus not requiring API keys or subscriptions.

Subscription-Based Coding Agents

The most prominent subscription-based coding agents are parts of IDEs like Windsurf, Cursor and VSCode. Serena's functionality is similar to Cursor's Agent, Windsurf's Cascade or VSCode's upcoming agent mode.

Serena has the advantage of not requiring a subscription. A potential disadvantage is that it is not directly integrated into an IDE, so the inspection of newly written code is not as seamless.

More technical differences are:

  • Serena is not bound to a specific IDE. Serena's MCP server can be used with any MCP client (including some IDEs), and the Agno-based agent provides additional ways of applying its functionality.

  • Serena is not bound to a specific large language model or API.

  • Serena navigates and edits code using a language server, so it has a symbolic understanding of the code. IDE-based tools often use a RAG-based or purely text-based approach, which is often less powerful, especially for large codebases.

  • Serena is open-source and has a small codebase, so it can be easily extended and modified.

API-Based Coding Agents

An alternative to subscription-based agents are API-based agents like Claude Code, Cline, Aider, Roo Code and others, where the usage costs map directly to the API costs of the underlying LLM. Some of them (like Cline) can even be included in IDEs as an extension. They are often very powerful and their main downside are the (potentially very high) API costs.

Serena itself can be used as an API-based agent (see the section on Agno above). We have not yet written a CLI tool or a dedicated IDE extension for Serena (and there is probably no need for the latter, as Serena can already be used with any IDE that supports MCP servers). If there is demand for a Serena as a CLI tool like Claude Code, we will consider writing one.

The main difference between Serena and other API-based agents is that Serena can also be used as an MCP server, thus not requiring an API key and bypassing the API costs. This is a unique feature of Serena.

Other MCP-Based Coding Agents

There are other MCP servers designed for coding, like DesktopCommander and codemcp. However, to the best of our knowledge, none of them provide semantic code retrieval and editing tools; they rely purely on text-based analysis. It is the integration of language servers and the MCP that makes Serena unique and so powerful for challenging coding tasks, especially in the context of larger codebases.

Acknowledgements

We built Serena on top of multiple existing open-source technologies, the most important ones being:

  1. multilspy. A library which wraps language server implementations and adapts them for interaction via Python and which provided the basis for our library Solid-LSP (src/solidlsp). Solid-LSP provides pure synchronous LSP calls and extends the original library with the symbolic logic that Serena required.

  2. Python MCP SDK

  3. Agno and the associated agent-ui, which we use to allow Serena to work with any model, beyond the ones supporting the MCP.

  4. All the language servers that we use through Solid-LSP.

Without these projects, Serena would not have been possible (or would have been significantly more difficult to build).

Customizing and Extending Serena

It is straightforward to extend Serena's AI functionality with your own ideas. Simply implement a new tool by subclassing serena.agent.Tool and implement the apply method with a signature that matches the tool's requirements. Once implemented, SerenaAgent will automatically have access to the new tool.

It is also relatively straightforward to add support for a new programming language.

We look forward to seeing what the community will come up with! For details on contributing, see here.

Full List of Tools

Here is the full list of Serena's tools with a short description (output of uv run serena-list-tools):

  • activate_project: Activates a project by name.

  • check_onboarding_performed: Checks whether project onboarding was already performed.

  • create_text_file: Creates/overwrites a file in the project directory.

  • delete_lines: Deletes a range of lines within a file.

  • delete_memory: Deletes a memory from Serena's project-specific memory store.

  • execute_shell_command: Executes a shell command.

  • find_referencing_code_snippets: Finds code snippets in which the symbol at the given location is referenced.

  • find_referencing_symbols: Finds symbols that reference the symbol at the given location (optionally filtered by type).

  • find_symbol: Performs a global (or local) search for symbols with/containing a given name/substring (optionally filtered by type).

  • get_active_project: Gets the name of the currently active project (if any) and lists existing projects

  • get_current_config: Prints the current configuration of the agent, including the active modes, tools, and context.

  • get_symbols_overview: Gets an overview of the top-level symbols defined in a given file or directory.

  • initial_instructions: Gets the initial instructions for the current project. Should only be used in settings where the system prompt cannot be set, e.g. in clients you have no control over, like Claude Desktop.

  • insert_after_symbol: Inserts content after the end of the definition of a given symbol.

  • insert_at_line: Inserts content at a given line in a file.

  • insert_before_symbol: Inserts content before the beginning of the definition of a given symbol.

  • list_dir: Lists files and directories in the given directory (optionally with recursion).

  • list_memories: Lists memories in Serena's project-specific memory store.

  • onboarding: Performs onboarding (identifying the project structure and essential tasks, e.g. for testing or building).

  • prepare_for_new_conversation: Provides instructions for preparing for a new conversation (in order to continue with the necessary context).

  • read_file: Reads a file within the project directory.

  • read_memory: Reads the memory with the given name from Serena's project-specific memory store.

  • replace_lines: Replaces a range of lines within a file with new content.

  • replace_symbol_body: Replaces the full definition of a symbol.

  • restart_language_server: Restarts the language server, may be necessary when edits not through Serena happen.

  • search_for_pattern: Performs a search for a pattern in the project.

  • summarize_changes: Provides instructions for summarizing the changes made to the codebase.

  • switch_modes: Activates modes by providing a list of their names

  • think_about_collected_information: Thinking tool for pondering the completeness of collected information.

  • think_about_task_adherence: Thinking tool for determining whether the agent is still on track with the current task.

  • think_about_whether_you_are_done: Thinking tool for determining whether the task is truly completed.

  • write_memory: Writes a named memory (for future reference) to Serena's project-specific memory store.

Available Tools

33 tools
activate_projectC

Activates the project with the given name.

Inputs: project (required).

check_onboarding_performedA

Checks whether project onboarding was already performed. You should always call this tool before beginning to actually work on the project/after activating a project, but after calling the initial instructions tool.

Inputs: no named parameters.

create_text_fileA

Write a new file (or overwrite an existing file). For existing files, it is strongly recommended to use symbolic operations like replace_symbol_body or insert_after_symbol/insert_before_symbol, if possible. You can also use insert_at_line to insert content at a specific line for existing files if the symbolic operations are not the right choice for what you want to do.

If ever used on an existing file, the content has to be the complete content of that file (so it may never end with something like "The remaining content of the file is left unchanged."). For operations that just replace a part of a file, use the replace_lines or the symbolic editing tools instead. Returns a message indicating success or failure.

Inputs: relative_path (required), content (required).

delete_linesA

Deletes the given lines in the file. Requires that the same range of lines was previously read using the read_file tool to verify correctness of the operation.

Inputs: relative_path (required), start_line (required), end_line (required).

delete_memoryA

Delete a memory file. Should only happen if a user asks for it explicitly, for example by saying that the information retrieved from a memory file is no longer correct or no longer relevant for the project.

Inputs: memory_file_name (required).

execute_shell_commandA

Execute a shell command and return its output.

IMPORTANT: you should always consider the memory about suggested shell commands before using this tool. If this memory was not loaded in the current conversation, you should load it using the read_memory tool before using this tool.

You should have at least once looked at the suggested shell commands from the corresponding memory created during the onboarding process before using this tool. Never execute unsafe shell commands like rm -rf / or similar! Generally be very careful with deletions. Returns a JSON object containing the command's stdout and optionally stderr output.

Inputs: command (required), cwd, capture_stderr, max_answer_chars.

find_fileA

Finds non-gitignored files matching the given file mask within the given relative path. Returns a JSON object with the list of matching files.

Inputs: file_mask (required), relative_path (required).

find_referencing_symbolsB

Finds symbols that reference the symbol at the given name_path. The result will contain metadata about the referencing symbols as well as a short code snippet around the reference (unless include_body is True, then the short snippet will be omitted). Note that among other kinds of references, this function can be used to find (direct) subclasses of a class, as subclasses are referencing symbols that have the kind class. Returns a list of JSON objects with the symbols referencing the requested symbol.

Inputs: name_path (required), relative_path (required), include_kinds, exclude_kinds, +1 more.

find_symbolA

Retrieves information on all symbols/code entities (classes, methods, etc.) based on the given name_path, which represents a pattern for the symbol's path within the symbol tree of a single file. The returned symbol location can be used for edits or further queries. Specify depth > 0 to retrieve children (e.g., methods of a class).

The matching behavior is determined by the structure of name_path, which can either be a simple name (e.g. "method") or a name path like "class/method" (relative name path) or "/class/method" (absolute name path). Note that the name path is not a path in the file system but rather a path in the symbol tree within a single file. Thus, file or directory names should never be included in the name_path. For restricting the search to a single file or directory, the within_relative_path parameter should be used instead. The retrieved symbols' name_path attribute will always be composed of symbol names, never file or directory names.

Key aspects of the name path matching behavior:

  • Trailing slashes in name_path play no role and are ignored.

  • The name of the retrieved symbols will match (either exactly or as a substring) the last segment of name_path, while other segments will restrict the search to symbols that have a desired sequence of ancestors.

  • If there is no starting or intermediate slash in name_path, there is no restriction on the ancestor symbols. For example, passing method will match against symbols with name paths like method, class/method, class/nested_class/method, etc.

  • If name_path contains a / but doesn't start with a /, the matching is restricted to symbols with the same ancestors as the last segment of name_path. For example, passing class/method will match against class/method as well as nested_class/class/method but not method.

  • If name_path starts with a /, it will be treated as an absolute name path pattern, meaning that the first segment of it must match the first segment of the symbol's name path. For example, passing /class will match only against top-level symbols like class but not against nested_class/class. Passing /class/method will match against class/method but not nested_class/class/method or method. Returns JSON string: a list of symbols (with locations) matching the name.

Inputs: name_path (required), depth, relative_path, include_body, +4 more.

get_current_configB

Print the current configuration of the agent, including the active and available projects, tools, contexts, and modes.

Inputs: no named parameters.

get_symbols_overviewA

Gets an overview of the given file or directory. For each analyzed file, we list the top-level symbols in the file (name_path, kind). Use this tool to get a high-level understanding of the code symbols. Calling this is often a good idea before more targeted reading, searching or editing operations on the code symbols. Returns a JSON object mapping relative paths of all contained files to info about top-level symbols in the file (name_path, kind).

Inputs: relative_path (required), max_answer_chars.

initial_instructionsA

Get the initial instructions for the current coding project. You should always call this tool before starting to work (including using any other tool) on any programming task! The only exception is when a user asks you to activate a project, in which case you should call the activate_project first instead and then call this tool.

Inputs: no named parameters.

insert_after_symbolA

Inserts the given body/content after the end of the definition of the given symbol (via the symbol's location). A typical use case is to insert a new class, function, method, field or variable assignment.

Inputs: name_path (required), relative_path (required), body (required).

insert_at_lineA

Inserts the given content at the given line in the file, pushing existing content of the line down. In general, symbolic insert operations like insert_after_symbol or insert_before_symbol should be preferred if you know which symbol you are looking for. However, this can also be useful for small targeted edits of the body of a longer symbol (without replacing the entire body).

Inputs: relative_path (required), line (required), content (required).

insert_before_symbolA

Inserts the given body/content before the beginning of the definition of the given symbol (via the symbol's location). A typical use case is to insert a new class, function, method, field or variable assignment. It also can be used to insert a new import statement before the first symbol in the file.

Inputs: name_path (required), relative_path (required), body (required).

list_dirA

Lists all non-gitignored files and directories in the given directory (optionally with recursion). Returns a JSON object with the names of directories and files within the given directory.

Inputs: relative_path (required), recursive (required), max_answer_chars.

list_memoriesB

List available memories. Any memory can be read using the read_memory tool.

Inputs: no named parameters.

onboardingA

Call this tool if onboarding was not performed yet. You will call this tool at most once per conversation. Returns instructions on how to create the onboarding information.

Inputs: no named parameters.

prepare_for_new_conversationB

Instructions for preparing for a new conversation. This tool should only be called on explicit user request.

Inputs: no named parameters.

read_fileA

Reads the given file or a chunk of it. Generally, symbolic operations like find_symbol or find_referencing_symbols should be preferred if you know which symbols you are looking for. Reading the entire file is only recommended if there is no other way to get the content required for the task. Returns the full text of the file at the given relative path.

Inputs: relative_path (required), start_line, end_line, max_answer_chars.

read_memoryA

Read the content of a memory file. This tool should only be used if the information is relevant to the current task. You can infer whether the information is relevant from the memory file name. You should not read the same memory file multiple times in the same conversation.

Inputs: memory_file_name (required), max_answer_chars.

remove_projectC

Removes a project from the Serena configuration.

Inputs: project_name (required).

replace_linesA

Replaces the given range of lines in the given file. Requires that the same range of lines was previously read using the read_file tool to verify correctness of the operation.

Inputs: relative_path (required), start_line (required), end_line (required), content (required).

replace_regexA

Replaces one or more occurrences of the given regular expression. This is the preferred way to replace content in a file whenever the symbol-level tools are not appropriate. Even large sections of code can be replaced by providing a concise regular expression of the form "beginning.*?end-of-text-to-be-replaced". Always try to use wildcards to avoid specifying the exact content of the code to be replaced, especially if it spans several lines.

IMPORTANT: REMEMBER TO USE WILDCARDS WHEN APPROPRIATE! I WILL BE VERY UNHAPPY IF YOU WRITE LONG REGEXES WITHOUT USING WILDCARDS INSTEAD!.

Inputs: relative_path (required), regex (required), repl (required), allow_multiple_occurrences.

replace_symbol_bodyC

Replaces the body of the symbol with the given name_path.

Inputs: name_path (required), relative_path (required), body (required).

restart_language_serverA

Use this tool only on explicit user request or after confirmation. It may be necessary to restart the language server if the user performs edits not through Serena, so the language server state becomes outdated and further editing attempts lead to errors.

If such editing errors happen, you should suggest using this tool.

Inputs: no named parameters.

search_for_patternA

Offers a flexible search for arbitrary patterns in the codebase, including the possibility to search in non-code files. Generally, symbolic operations like find_symbol or find_referencing_symbols should be preferred if you know which symbols you are looking for.

Pattern Matching Logic: For each match, the returned result will contain the full lines where the substring pattern is found, as well as optionally some lines before and after it. The pattern will be compiled with DOTALL, meaning that the dot will match all characters including newlines. This also means that it never makes sense to have .* at the beginning or end of the pattern, but it may make sense to have it in the middle for complex patterns. If a pattern matches multiple lines, all those lines will be part of the match. Be careful to not use greedy quantifiers unnecessarily, it is usually better to use non-greedy quantifiers like .*? to avoid matching too much content.

File Selection Logic: The files in which the search is performed can be restricted very flexibly. Using restrict_search_to_code_files is useful if you are only interested in code symbols (i.e., those symbols that can be manipulated with symbolic tools like find_symbol). You can also restrict the search to a specific file or directory, and provide glob patterns to include or exclude certain files on top of that. The globs are matched against relative file paths from the project root (not to the relative_path parameter that is used to further restrict the search). Smartly combining the various restrictions allows you to perform very targeted searches. Returns A JSON object mapping file paths to lists of matched consecutive lines (with context, if requested).

Inputs: substring_pattern (required), context_lines_before, context_lines_after, paths_include_glob, +4 more.

summarize_changesA

Summarize the changes you have made to the codebase. This tool should always be called after you have fully completed any non-trivial coding task, but only after the think_about_whether_you_are_done call.

Inputs: no named parameters.

switch_modesC

Activates the desired modes, like ["editing", "interactive"] or ["planning", "one-shot"].

Inputs: modes (required).

think_about_collected_informationA

Think about the collected information and whether it is sufficient and relevant. This tool should ALWAYS be called after you have completed a non-trivial sequence of searching steps like find_symbol, find_referencing_symbols, search_files_for_pattern, read_file, etc.

Inputs: no named parameters.

think_about_task_adherenceA

Think about the task at hand and whether you are still on track. Especially important if the conversation has been going on for a while and there has been a lot of back and forth.

This tool should ALWAYS be called before you insert, replace, or delete code.

Inputs: no named parameters.

think_about_whether_you_are_doneC

Whenever you feel that you are done with what the user has asked for, it is important to call this tool.

Inputs: no named parameters.

write_memoryA

Write some information about this project that can be useful for future tasks to a memory. Use markdown formatting for the content. The information should be short and to the point. The memory name should be meaningful, such that from the name you can infer what the information is about. It is better to have multiple small memories than to have a single large one because memories will be read one by one and we only ever want to read relevant memories.

This tool is either called during the onboarding process or when you have identified something worth remembering about the project from the past conversation.

Inputs: memory_name (required), content (required), max_answer_chars.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    B3.4/5.0

    Scored across 33 tools

    Disambiguation3/5

    The tool set has clear distinctions for core operations like file editing and symbol manipulation, but there is significant overlap in search and reading tools (e.g., find_symbol, search_for_pattern, read_file) that could cause confusion. Additionally, multiple 'think about' tools have very similar purposes, making it hard for an agent to choose the right one without careful reading of descriptions.

    Naming Consistency4/5

    Most tools follow a consistent verb_noun or verb_preposition_noun pattern (e.g., create_text_file, delete_lines, insert_after_symbol), which is predictable. However, there are minor deviations like 'get_current_config' (verb_adjective_noun) and 'onboarding' (noun-only), slightly breaking the pattern but not severely impacting readability.

    Tool Count2/5

    With 33 tools, the count is excessive for a coding assistant server, leading to cognitive overload and potential redundancy. Many tools could be consolidated (e.g., multiple 'think about' tools) without losing functionality, making the set feel bloated and difficult to navigate efficiently.

    Completeness5/5

    The tool set comprehensively covers the domain of code project management, including project activation, file operations (create, read, edit, delete), symbol manipulation, memory handling, and reflective tools for task adherence. There are no obvious gaps; it supports full CRUD and lifecycle workflows for coding tasks.

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      D
      maintenance
      Provides LLM Agents with AI-powered mentorship for code review, design critique, writing feedback, and brainstorming using the Deepseek API, enabling enhanced output in various development and strategic planning tasks.
      5
      32
      Apache 2.0
    • A
      license
      Not graded
      quality
      D
      maintenance
      A local vector database system that provides LLM coding agents with fast, efficient semantic search capabilities for software projects via the Message Control Protocol.
      7
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      A fully featured coding agent that uses symbolic operations (enabled by language servers) and works well even in large code bases. Essentially a free to use alternative to Cursor and Windsurf Agents, Cline, Roo Code and others.
      29
      31,112
      GPL 3.0
    • A
      license
      A
      quality
      F
      maintenance
      Unleashes LLM-powered agents to autonomously execute and debug web apps directly in your code editor, with features like webapp navigation, network traffic capture, and console error collection.
      2
      1,232
      Apache 2.0