AnomalyArmor

Data observability tools for engineering teams: alerts, freshness, schema drift, lineage, quality.

AnomalyArmor is an MCP server that brings data observability capabilities to engineering teams. It is published by ai.anomalyarmor, available via PyPI as armor-mcp at version 0.6.1, and communicates over stdio transport. It requires an ARMOR_API_KEY environment variable to authenticate with the AnomalyArmor service.

The server focuses on five observability concerns: alerting on data anomalies, checking data freshness, detecting schema drift, tracking data lineage, and assessing data quality. These capabilities allow an AI agent integrated with this MCP server to interact with an AnomalyArmor backend to surface issues in data pipelines — for example, identifying when a table has not been updated within an expected window, when column types or names have changed unexpectedly, or when quality metrics fall outside acceptable thresholds.

This server is intended for engineering teams that already use or plan to use the AnomalyArmor platform. Because it operates over stdio, it is suited to local agent setups or subprocess-based orchestration rather than networked deployments. No tool definitions were published with this registry record, so the exact callable operations exposed to an agent are not documented here; refer to the upstream repository at github.com/anomalyarmor/agents for current tool details before integrating.

Use cases

  • Monitor data pipeline freshness and alert when datasets are stale
  • Detect schema drift in database tables across pipeline runs
  • Track data lineage to trace the origin and flow of datasets
  • Surface data quality issues to an agent for automated triage
  • Trigger observability alerts when anomalies are detected in ingestion

When to use it

  • The team uses the AnomalyArmor platform and has a valid API key
  • An agent needs to check data freshness or quality as part of a workflow
  • Schema drift detection is required in an automated pipeline monitoring context
  • Local or subprocess-based stdio agent orchestration is already in use

When not to use it

  • No AnomalyArmor account or API key is available
  • A networked or HTTP-based MCP transport is required instead of stdio
  • The goal is direct SQL querying of a Postgres database rather than observability monitoring
  • A fully self-contained open-source observability solution with no external service dependency is needed