Serena's free backend is a language server, its paid one is your IDE

Two backends, and the paid one skips Rider and CLion

The semantic tools are powered by one of two things. The default is a set of language servers implementing the language server protocol, described as the free open-source alternative, and Serena wraps them in an abstraction layer so the tools stay the same across languages. Support is claimed for over 40 languages, from Ada and C through Go, Haskell, Lean 4, MATLAB, Rego, Solidity, Terraform, Wolfram Language and Zig.

The alternative is the Serena JetBrains Plugin, which borrows the analysis engine of a JetBrains IDE. It is a paid plugin with a free trial, and it covers whatever a JetBrains IDE supports: IntelliJ IDEA, PyCharm, Android Studio, WebStorm, PhpStorm, RubyMine, GoLand. Two are named as unsupported, Rider and CLion, which is the kind of detail that decides this purchase for teams that work in those two IDEs.

So the free path costs you per-language server quality, and the paid path costs you a licence and a plugin that does not cover every JetBrains user.

The compose file starts a server with no project mounted

compose.yaml is a usable starting point, and the first thing to notice is that the volumes are commented out. The file says you must mount projects into /workspace/ in the container, then shows the two lines that would do it, both disabled. Starting the stack as shipped gives you a running serena-mcp-server with nothing to read and nothing to edit. Uncommenting them is step one, not an optional extra.

The port mapping is the other detail worth reading twice:

    ports:
      - "127.0.0.1:${SERENA_PORT:-9121}:9121"
      - "127.0.0.1:${SERENA_DASHBOARD_PORT:-24282}:24282"

Both are published to loopback, which is what keeps the server private, because the command itself listens wider:

      - "uv run --directory . serena-mcp-server --transport sse --port 9121 --host 0.0.0.0"

A reader who changes the left-hand side of a mapping to a routable address to reach the server from another machine also removes the only protection, and no authentication option appears in the compose file or in that command.

Two connection styles, one of them needs a URL

Connecting a client takes one of two forms. Either the client gets a launch command that starts the MCP server itself, or you start the server in HTTP mode and hand the client a URL. The second is the shape used in the compose file, where the transport is sse on port 9121 with the environment variable SERENA_DOCKER set to 1.

The client list is long enough that the compatibility question is usually settled already: terminal clients such as Claude Code, Codex, OpenCode and Gemini-CLI, IDEs and their assistant plugins for VSCode, Cursor and the JetBrains family including Copilot, Junie and JetBrains AI Assistant, and desktop or web clients such as Claude Desktop, the Codex App and OpenWebUI. Any of them that speaks MCP can take the launch command.

What Serena is not is an agent. The README is blunt that it supplies the tools for coding workflows while an LLM does the actual work and orchestrates tool use. A memory system for long-lived agent workflows sits alongside, and the tool design deliberately stays at symbol level and relational structure rather than line numbers and primitive search patterns. The project also ships a pygls-based msl language server, which is how one of the listed languages gets covered.

uvx ignores the lock file, so pyproject is the real lock

The dependency block carries two comments that explain the pinning strategy, and the second one changes how you should read the project:

  # Transitive deps pinned for security (dependabot alerts).
  # Exact pins because uvx installs from git, ignoring the lock file.

There is a uv.lock in the repository, and the Docker path uses it, since the container command runs uv against the working directory. The uvx path does not, because an install from git resolves from pyproject.toml. That is why urllib3, werkzeug, starlette, python-multipart, filelock, cryptography and regex are all pinned to exact versions next to the direct dependencies, and why the flask pin carries the note that it was bumped from 3.1.1 for a CVE fix.

The consequence for anyone running this in a company is that dependency maintenance is a code change, not a lock file update. Every transitive security alert turns into a pull request against pyproject.toml, and the two install paths can hand you different trees for the same commit.

main is a 2.0.0 dev tree while the newest tag is v1.7.0

pyproject declares version 2.1.1.dev0 on the default branch. The newest release is v2.1.0 from 2026-10-19, with v2.0.0 from 2026-10-13 and v1.7.0 from 2026-08-09 behind it, so a reader who installs the tagged release and a colleague who runs the branch from git can be on different code.

Python support is stated precisely, which is at least unambiguous: requires-python is >=3.11, <3.15, and the classifiers list 3.11 through 3.14. A team still on 3.10 is outside the range, and one on 3.15 has no classifier and no guarantee.

The last push was on 2026-09-30. The 2.0 line has since been tagged as v2.0.0 and v2.1.0, the README announces Serena v2 with a new REPL-based agent interface, and the repository carries a CHANGELOG.md and a news/ directory.

The instruction not to use the marketplace is the install warning

The most emphatic line in the README is a prohibition. Do not install Serena through an MCP or plugin marketplace, because those contain outdated and suboptimal installation commands, and follow the Quick Start instead. That matters for anyone using an editor with a built-in add-server button, since the button is the path that reaches for a stale command first.

The concrete reference is the Quick Start section and the documentation site at oraios.github.io/serena. One command that is fully spelled out in the repository is the container launch string quoted earlier, which is the most reliable thing to copy while you read the rest.

Two files at the root tell you what the project expects around it. A .env.example holds placeholder values for GOOGLE_API_KEY and ANTHROPIC_API_KEY, and the dependency list includes the anthropic client.

The evaluation evidence is produced by the project itself

The case for Serena rests on an evaluation the authors ran. The framing is that humans install it but the end users are the agents, so a single unbiased prompt was written to put an agent through roughly 20 routine coding tasks representative of everyday work, and the value added over an agent's own built-in tools was measured. Three results are quoted: Opus 4.6 at high reasoning in Claude Code on a large Python codebase, GPT 5.4 at high in Codex CLI on a Java codebase, and GPT 5.4 at medium in Copilot CLI on a large multi-language monorepo.

Read the third quote closely, because it is the most useful of the three. That agent says it still leans on built-ins for tiny text edits and non-code work, which is the honest shape of the claim: symbol-level work is what moves, everything else stays where it was.

On licensing, the facts do not line up neatly. pyproject declares GPL-3.0-or-later with license-files pointing at LICENSE and LICENSES/*, and there is a CLA.md, while the repository's own license field resolves to NOASSERTION. A GPL release is reciprocal, so a company embedding the server in a product needs to read LICENSE and LICENSES/ before it ships, and no packaging tool that reads repository metadata will tell them anything useful.

Editorial conclusion

Serena fits a team that already runs an MCP client and wants its agent to work on symbols rather than line numbers, and that is willing to either install language servers per language or buy the JetBrains plugin. It does not fit a reader who expects a plug-and-play server, because the Docker default mounts no project. Check which of the two you install first, the v2.1.0 tag or main (2.1.1.dev0), then decide which backend you will pay for and whether your IDE is one of the two the paid plugin does not support.

Frequently asked questions

Official sources

1. License: MIT
2. oraios/serena on GitHub
3. Project website
4. README
5. Releases