Skip to content

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:

claude mcp add dense_armor -- dense-armor-mcp

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:

{
  "mcpServers": {
    "dense_armor": {
      "command": "dense-armor-mcp"
    }
  }
}

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 — run Armatura.analizza on 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 — call Orca.protect_and_forward on 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.