etna-mcp

# Etna A tool server built for agentic harnesses. Etna gives you tool isolation out of the box — each kit is its own branch of the tool tree, independently toggleable per session. Drop a Python file in, and it's live. Kit authoring is intentionally Pythonic: a decorator, type hints, and a docstring are all the model needs to understand and use a tool. Everything else — schema generation, dependency management, client registration, hot-reload — is handled for you. ## Why Etna instead of MCP MCP solves the problem of getting tools into models, and it does that well. What it doesn't solve is what happens when you have a lot of them. The standard answer is to run a separate server process per tool category and register each one individually in your client config. That works, but it means your tool surface area is defined at the process level — adding a capability requires restarting something, and toggling access requires editing a config file. Etna takes a different position. One server, one connection, all your kits. Isolation happens at the kit level inside that single process — each kit is its own independently toggleable branch of the tool tree. A harness can expose different kits to different models, different sessions, or different users, all from the same running server. No additional processes, no config restarts. MCP compatibility ships as an adapter so Etna works with any client that already speaks MCP. But the Etna Protocol is its own thing — built directly on LLM tool use, not on top of MCP. ## How it works - **CLI (`etna`)** — manages the full lifecycle. Install kits, start the server, configure clients, manage Chrome for browser automation. One command for everything. - **Kits (`~/.etna_server/kits/`)** — each kit is a plain Python file with `@tool`-decorated functions and four metadata fields. Drop one in, and it's live. - **Server** — FastAPI process that auto-discovers all kits at startup and again on hot-reload. Speaks both the Etna Protocol …