MCP Server¶
This is a small program that lets an AI assistant use Dense-Armor's tools directly, as if they were its own, without importing the library.
Dense-Armor ships a Model Context Protocol server: a small process that exposes the library's shields and detectors over the MCP protocol, so an LLM agent that already speaks MCP can call them as tools without importing anything.
The page is a thin shell around the server's own README.md, which is the single
source of truth for installation, tool names, and configuration. It is pulled in
directly from dense_armor/mcp_server/README.md, so it never goes stale relative to
the code.
dense_armor_mcp¶
An MCP server that lets Claude (or any MCP client) call Dense-Armor's anomaly-shielding functions directly -- clean a corrupted series, classify each point as an isolated spike vs a genuine regime change, or run the classic robust-statistics detectors -- without writing Python.
Unlike Dense-Evolution's MCP adapter (a thin HTTP proxy to a separately running FastAPI kernel
behind its Composer web UI), this one is direct, in-process: Dense-Armor has no web UI/kernel
to share, and its operations are lightweight pure NumPy/JAX calls with no reason to live in a
separate long-running process. Every tool here imports and calls dense_armor directly, in this
same process -- no separate server to start first.
1. Install this server's dependencies¶
pip install -e ".[mcp]" # if you have the repo checked out
pip install "dense-armor[mcp]" # from PyPI, once published
# or, standalone without the extras mechanism:
pip install -r dense_armor/mcp_server/requirements.txt
2. Register it with your MCP client¶
Claude Code:
dense-armor-mcp is the console-script entry point ([project.scripts] in pyproject.toml,
separate from dense-armor itself, Armatura's own CLI) -- it just calls this file's main().
Running python /absolute/path/to/dense_armor/mcp_server/server.py directly still works too,
e.g. if you haven't installed the package.
Note: this lives at dense_armor.mcp_server, not a bare mcp_server -- Dense-Evolution's own
adapter is (confusingly) also just called mcp_server, and with both packages installed in the
same environment a bare top-level name is a real, observed collision, not a hypothetical one.
Manual .mcp.json / claude_desktop_config.json entry:
Tools¶
| Tool | What it does |
|---|---|
dense_armor_health |
Confirms dense_armor is importable, reports host RAM/backend -- call first if unsure. |
dense_armor_clean_signal |
Runs the full Orca shield over a raw series (Orca's own "simple data test" mode, no AI model in the loop). Optional x_reference; optional use_arbiter for per-point routing. |
dense_armor_detect_anomalies |
Classifies each point as clean/spike/regime without correcting anything -- the routing logic behind use_arbiter, exposed standalone. |
dense_armor_robust_filter |
One of the four classic detectors (Chauvenet, Tukey, Hampel, sigma-clipping) or their combined pressure_valve orchestrator. |
dense_armor_heal_series |
The neighbor-consensus healing_filter -- strong on pervasive noise and genuine sustained jumps, standalone. |
dense_armor_stream_start |
Opens a real-time streaming session (one MultiChannelStreamingDeviationDetector kept in server memory) -- for a live sensor stream where waiting to collect a full array first isn't an option. Returns a session_id. |
dense_armor_stream_update |
Feeds one real-time reading (one value per channel) into an open session, returns that instant's deviation flag per channel. Call once per real sensor reading, in order -- the detector's state advances with every call. |
dense_armor_stream_end |
Closes a session and frees its state. Sessions are not garbage-collected automatically. |
The 3 streaming tools are stateful (session-based), unlike every other tool above, which
are pure functions of their inputs. See utility/streaming.py/docs/api/streaming.md for the
underlying detector, validated on two independent real physical domains before promotion.
Every tool takes/returns plain JSON (None/null for a missing reading -- converted to/from
NaN internally, since raw JSON has no NaN literal). See models.py for the exact input schema
of each, or docs/api/arbiter.md /
docs/api/orca.md for the underlying
functions' full documentation.
What the server exposes¶
Three tool families, one for each shield entry point:
shield_series— runArmatura.analizzaon a 1D array and return the cleaned series, the anomaly count, and the list of replaced indices. Use this when an agent has a numeric series (a loss curve, a sensor channel) and wants it cleaned before reasoning about it.shield_model— callOrca.protect_and_forwardon a small tensor. The model itself is passed as a reference to a callable that the MCP server holds, so the agent does not have to send model weights over the wire. Use this when the agent generates candidate inputs and wants to know whether they look corrupted.detect_drift— run the CUSUM detector on a stream and return the alarm indices and the ARL estimates for the parameters used. Use this when an agent is monitoring a stream of measurements and wants an early warning on a slow change.
The server does not run models. It runs the shields and the detectors on data the agent provides, and returns the result. Nothing else.
Why an MCP server at all¶
An agent that already has the library installed can call it directly. But in a multi-agent setup, or in a hosted agent that has no local Python, an MCP server is the standard way to expose a capability. The three tools above are the ones that make sense to expose: an agent that wants to clean a series, protect a small forward pass, or watch for a drift, without pulling in a JAX dependency just to do it.