arno

ARNO (Agent Repository Navigation & Operations) is an MCP server for coding agents, positioned as "the IDE for agents." It provides coding agents, through the MCP protocol, with the capabilities an IDE usually gives developers: reading code by symbol, editing based on a known revision, returning compiler diagnostics on edit, verifying using the repository's own commands, viewing changes, and rolling back to a checkpoint. Every step is a tool call, and does not go through a shell.

Purpose and Design Goals

The core goal of ARNO is to solve the problem of agents bypassing controlled tools and directly using the shell (grep, sed, cat). When an agent falls back to the shell, there is no revision tracking, no guardrails, no telemetry, and no way to know what it did and why it did it that way. Merely prompting the model not to use the shell cannot fundamentally solve this, because the shell is cheaper—fewer tokens, fewer round trips, and more flexible. Therefore, ARNO's approach is to make structured tools the cheaper choice, and to measure success through benchmarks.

Main Capabilities

• Read code by symbol: ARNO navigates the codebase in a symbol-aware way.
• Edit based on revision: edits are made against a known revision.
• Compiler diagnostics: compiler diagnostics are returned on edit.
• Repository command verification: verify using the repository's own build and test commands.
• View changes and roll back: view the content of changes, and roll back to a checkpoint.
• Language support: Go, Java, Scala, TypeScript, Python, Rust, Ruby.
• Language server integration: precise references, cross-file renaming, and type errors on edit require the corresponding language server; when no server is installed, ARNO will explain which answers are approximate, and a missing server will not be treated as an error.
• Repository command declaration: agents can declare commonly used commands via declare_command, and subsequent sessions reuse them from .arno/commands.json.
• Telemetry: arno.telemetry is local telemetry, does not record parameters or response text, and does not contain source code.

Usage

ARNO is a stdio MCP server. Installation methods include:

• Installation script: download the latest release binary for the corresponding operating system and CPU, verify it with checksums.txt, no su requireddo installs to /usr/local/bin or ~/.local/bin. Run the same command again to update.
• Go install: go install github.com/julianbei/arno/cmd/arno-mcp@latest.
• Prebuilt binaries: GitHub releases include amd64 and arm64 binaries for linux and darwin, plus checksums.txt.
• MCPB package: since 0.0.11, each GitHub release includes arno-mcp_<version>.mcpb, which can be opened with Claude Desktop.
• Containers: container images are provided, statically linked with musl.

Language servers can be installed through the arno-mcp install menu, or manually (such as gopls, jdtls, metals, TypeScript, Pyright, rust-analyzer, ruby-lsp). For agents or scripts, use --list --json to get each server's status and install command.

When configuring an MCP client, you need to point the client at the arno-mcp binary. ARNO_WORKSPACE_ROOT specifies the repository to inspect and edit; the --root /path/to/repo flag takes precedence over the environment variable, and at startup it prints which of the three sources (flag, environment variable, working directory) was used.

In Claude Code, you can put the configuration in .mcp.json at the repository root. It is recommended to let ARNO replace the built-in tools, because the entire tool list is resent every turn, and Claude Code's built-in tools take up about 38k tokens. Use arno.json to pass in the core configuration, listing twelve tools (read, edit, verify, run commands declared by the repository); other tools can still be called. Note: without Bash, the agent cannot run arbitrary commands; tasks that need git operations, network access, or temporary scripts still need a shell.

Other client configuration: Codex CLI is configured in ~/.codex/config.toml; goose can be added via the command line or goose configure; OpenCode is configured in opencode.json , and tools appear as arno_arno_find and so on. Cline and Gemini CLI have not yet been verified.

When to use

• Coding agents performing code lookup, reference analysis, cross-file renaming, multi-location changes, and build verification in real repositories.
• Running specific tests or test files.
• Declaring and reusing common repository commands.
• Creating checkpoints before risky operations, and rolling back when something goes wrong.

Limitations and notes

• Platform: macOS and Linux are supported; Windows is not supported (WSL 2 runs Linux, but it has not been tested and bug reports are not accepted).
• Known JVM issues: no formatter runs for Java or Scala files; large Gradle builds can make jdtls's first response much slower than 8.5 seconds; Kotlin is not yet supported.
• Non-git directories or repositories with no commits yet: changes, diff, history, and checkpoint require git and will state the degradation; other features still work.
• One server serves one repository, but can serve any of its worktrees; ARNO is fixed to the startup directory, and cd in the shell cannot affect it.
• In Claude Code, if "alwaysLoad": true is not set, ARNO may never be used, because MCP tools are hidden behind tool search by default.
• Benchmark results: in this repository's benchmark, ARNO's token usage for answering seven realistic engineering questions was 0.85 times that of equivalent shell commands; for one question in an unrelated repository it was 1.36 times. In the 0.0.4 pilot across four external repositories, when replacing Claude Code's built-in tools it solved 12 of 12 real problems, with 51% fewer tokens, and 18–25% fewer than a shell trimmed to four tools. These results have caveats; see the documentation for details.
• Current version 0.0.14, the first version without the Jade name; 0.0.11 and earlier were Jade.
• Installing language servers is a global package installation and is deliberately not an MCP tool; it requires approval through the agent shell.

For more details (such as benchmarks, response style, feedback logs, and tester guide), see the project documentation.