Back to MCP Servers

Daimonos

Agent-optimized MCP server replacing built-in file, search, exec, and git tools with compact structured JSON. Native plugins for git, cargo, gh, and docker. Semantic output filtering, read deduplication, batch operations, and token analytics. Benchmarked 20-45% token savings.

developer-toolsgodockeraiagent
By beardfaceguy
2Updated 1 day agoRustMIT

Installation

npx -y daimonos

Configuration

{
  "mcpServers": {
    "daimonos": {
      "command": "npx",
      "args": ["-y", "daimonos"]
    }
  }
}

How to use

  1. Run the installation command above (if needed)
  2. Open your Claude Code settings file (~/.claude/settings.json)
  3. Add the configuration to the mcpServers section
  4. Restart Claude Code to apply changes

Daimonos

CI Latest Release License: MIT MCP Registry

An agent-optimized OS layer that makes AI coding agents faster and cheaper.

Daimonos replaces the built-in file, search, exec, and git tools in your AI coding agent with structured equivalents that return compact JSON instead of raw terminal output. The result: fewer tokens consumed, fewer round-trips, and lower API costs — with zero changes to your workflow.

Platforms: Linux (x86_64, aarch64) and macOS (Apple Silicon, Intel). Windows support is planned.

For repository agent/operator conventions, see AGENTS.md (especially Daimonos tool usage policy).

The name comes from Greek daimon (agent/spirit), the etymological root of "daemon."

The problem

When an AI agent runs cargo test, it gets back hundreds of lines of terminal output — progress bars, compile messages, passing test names — when all it needs is "47 passed, 0 failed." The agent pays for every token of that noise: reading it, reasoning about it, and carrying it in context for the rest of the session.

The same waste happens with git status, docker ps, ls -la, and every other shell command. Agents spend 30-50% of their token budget on verbose, unstructured tool output.

How it works

Daimonos runs as an MCP server that your IDE or CLI spawns automatically. It provides the same operations agents already use — read files, write files, search, execute commands, git operations — but returns compact, structured JSON instead of raw text.

The single binary also provides ACP, one-shot agent, interactive chat, and socket-daemon runtimes — a full coding-agent harness in its own right; see Agent harness features below and Runtime modes for the explicit subcommands and compatibility aliases.

Agent: exec("cargo test")

Without Daimonos (raw terminal output):
   Compiling inventory v0.1.0 (/workspace)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 2.31s
     Running unittests src/main.rs (target/debug/deps/inventory-abc123)
running 47 tests
test config::tests::test_default ... ok
test config::tests::test_load ... ok
... (200+ more lines)
test result: ok. 47 passed; 0 failed; 0 ignored

With Daimonos (structured JSON):
{"ok":true,"tests":47,"passed":47,"failed":0,"failures":[]}

Four layers of optimization

  1. Native tool pluginsgit, cargo, gh, and docker are exposed as first-class MCP tools with structured JSON output. When agents call exec("cargo test"), Daimonos intercepts it and routes through the native plugin instead.

  2. Semantic output filters — For commands without native plugins (pytest, make, pip install, eslint, etc.), Daimonos applies semantic compression: test runners return summary + failures only, build commands return "ok" or just the errors, install commands return success/failure.

  3. Protocol-level efficiency — Read deduplication (re-reading an unchanged file returns {"unchanged":true} instead of the full content), compact field names, lazy tool exposure, batch operations, and a terse output directive that cuts LLM prose by ~30%.

  4. Managed subprocess execution — Command output is bounded while it is read instead of after full buffering. Daimonos owns Unix process groups, retires descendants on cancellation or session shutdown, isolates child environments through an explicit allowlist, and stores background output in private bounded artifacts.

Benchmark results

Tested with Claude Opus 4.6 on identical coding tasks (read files, search code, edit, run tests, git operations):

MetricBaselineDaimonosSavings
Output tokens5,8423,198-45.3%
Total tokens41,23933,847-17.9%
Tool calls17 avg14 avg-17.6%
Wall time42.1s avg35.2s avg-16.4%

Remote benchmarks on AWS (same hardware, same model, same tasks) showed 20.3% cost reduction and 14.0% faster task completion.

60-second demo

Use this script for README readers, release notes, and social posts:

# 1) Install daimonos
cargo build --release
sudo cp target/release/daimonos /usr/local/bin/

# 2) Configure your MCP client (example: Cursor)
# .cursor/mcp.json -> command: daimonos, args: ["--mcp", "-w", "/path/to/project"]

# 3) Ask your agent to run:
# "Run cargo test and summarize failures only."
# "Show git status as structured output."

What to highlight in the demo:

  • same workflows, less tool-output noise
  • structured responses instead of raw terminal spam
  • fewer tokens and fewer round-trips for common coding tasks

Quick start

Install

Pre-built binaries (Linux and macOS):

# Linux x86_64
curl -L https://github.com/beardfaceguy/daimonos/releases/latest/download/daimonos-x86_64-linux.tar.gz | tar xz
sudo mv daimonos /usr/local/bin/

# macOS Apple Silicon
curl -L https://github.com/beardfaceguy/daimonos/releases/latest/download/daimonos-aarch64-macos.tar.gz | tar xz
sudo mv daimonos /usr/local/bin/

From source:

git clone https://github.com/beardfaceguy/daimonos.git
cd daimonos
cargo build --release
sudo cp target/release/daimonos /usr/local/bin/

See docs/install.md for all platforms (ARM Linux, Intel Mac, musl static builds).

Configure your IDE

For most users, start with one of these:

Add Daimonos as an MCP server. For Cursor, add to your project's .cursor/mcp.json:

{
  "mcpServers": {
    "daimonos": {
      "command": "daimonos",
      "args": ["--mcp", "-w", "/path/to/your/project"]
    }
  }
}

That's it. Daimonos starts when your IDE opens the project and exits when you close it. No daemon to manage, no background service.

Setup guides for other tools

What's included

Core tools (always available)

ToolWhat it does
read_fileRead with optional offset/limit, content-hash deduplication
write_fileWrite with auto-mkdir
edit_fileString replacement with diff confirmation
searchRegex search (content mode) or file discovery (file mode)
execRun commands with semantic filtering, bounded capture, and owned teardown
batchMultiple operations in a single round-trip
workspace_infoProject type, git status, directory listing, analytics

Native tool plugins (auto-detected)

These appear automatically when the corresponding CLI tool is found on PATH:

PluginCommandsDetected by
gitstatus, log, diff, branch, add, commit, push, pull, checkout.git directory
cargotest, build, check, clippy, fmt, addCargo.toml
ghpr_view, pr_list, pr_create, pr_diff, pr_checks, apigh on PATH
dockerps, logs, exec, images, inspect, stop, compose_up/down/psdocker on PATH

Additional capabilities

  • Workspace snapshots — Checkpoint before risky edits, rollback on failure
  • Starlark scripting — Bundle multiple tool calls into a single script
  • Token analytics — Per-tool-call tracking with cross-session history (daimonos --stats)
  • Background processes — Start, poll, and stop long-running commands with admission limits, private bounded logs, and descendant cleanup
  • Configurable — All tunables in a single TOML config file

Managed process lifecycle

Raw exec, background jobs, and CLI plugins (cargo, git, gh, docker, npm, pytest, curl, and shellcheck) share one managed execution layer:

  • Streaming-time bounds — stdout and stderr retain UTF-8-safe head/tail previews without first allocating the complete output
  • Process-group ownership on Unix — cancellation and shutdown send TERM, wait a configurable grace period, then escalate to KILL and reap descendants
  • Secure background artifacts — random exclusive 0600 files under a private 0700 directory, with configurable byte and job-count limits
  • Environment isolation — children inherit only configured parent variables plus explicit session, tool, and per-call overrides; provider and MCP credentials are not ambiently leaked
  • Structured-output integrity — plugins reject truncated JSON rather than reporting an incomplete result as valid

Agent harness features

Beyond the MCP server, the same binary is a complete coding-agent harness: an interactive terminal UI (daimonos agent), an ACP backend for Zed, a one-shot CLI, and a session daemon with attach/detach and remote control.

Many of its recent features come from a systematic study of 60+ open-source agent harnesses (Aider, OpenHands, SWE-agent, Goose, OpenCode, Forge, Pi, the Cline family, and others) — mining the ecosystem for proven techniques and adapting the best ones.

Provider resilience — a hiccup never kills the turn

  • Bounded provider retries with backoff for transient failures (429/5xx/ network), classified at the provider boundary — fatal auth/validation errors surface immediately
  • Automatic model failover — on a sustained overload the turn continues on the next model in the chain, then returns to your preferred model on the next turn
  • Turn-level error resume — when retries and failover are spent, the agent pauses, repairs the conversation (keeping partial streamed output), and continues where it left off; recovery actions surface in the UI
  • Retry-storm detection — fingerprints repeated identical tool calls and steers the model out of loops
  • Orphan tool-call repair — max-token truncation mid-tool-call is repaired instead of poisoning the session

Multi-provider sessions

  • Several providers, one session — configure Anthropic, OpenAI, and OpenRouter side by side (DAIMONOS_AGENT_<NAME>_API_KEY); every call is routed to the right provider by model, with an explicit provider:slug override
  • Live model discovery — at startup the configured provider(s) are queried for their full model catalogs; the model picker and failover chain always reflect what is actually served, newest first
  • Cross-provider failover — with more than one provider configured, an outage at one can fail over to models at another, mid-turn
  • Provider-reported context windows — compaction thresholds derive from the live model metadata instead of hardcoded numbers

Context economy at the harness level

  • Conversation compaction — summarize-and-continue with high/low water-mark thresholds and provider-honest token accounting
  • Bounded tool results — oversized tool output is capped at the dispatch boundary and offloaded to

View source on GitHub