Skip to main content
Glama
automation-health-mcp

automation-health-mcp

by chainwright

automation-health-mcp

An MCP server that finds the automation which stopped working without telling anyone.

Most automation does not fail loudly. It keeps running, keeps exiting zero, keeps writing to its log — and quietly stops doing the work. The dashboard stays green. Nobody finds out until somebody asks a question about the numbers.

This server gives an LLM agent the tools to go and check.

> Audit the automation on this machine.

  critical  com.acme.sync           scheduled job is failing (exit code 1)
  critical  publisher.log           no output for 74h (threshold 26h)
  critical  api.example.com/accounts  HTTP 200 but 'data' is empty —
                                      the endpoint answers while holding nothing
  warning   worker.log              recent errors: login_required
  warning   billing.py:42           unfinished logic returning a hardcoded value

Why this exists

I audited my own stack and found six scheduled jobs that had been dead for weeks. Every one of them reported success in the way that mattered to whatever was watching:

  • a messaging job authenticated, received login_required, and exited quietly

  • a publishing integration returned HTTP 200 while holding zero connected accounts

  • a report had been renamed .DISABLED during debugging and never renamed back

  • a budget function read its input file, ignored it, and returned the constant it was seeded with

None of these are exotic. They are the normal ways automation dies, and none of them trip a conventional "is the process running" check.

Related MCP server: Audit Bridge MCP

What it checks

Tool

Question it answers

list_jobs

What is scheduled on this machine, and what did it exit with?

find_failing_jobs

Which scheduled jobs are failing right now?

check_log_freshness

Which daily jobs have produced no output in over a day?

check_recent_errors

Which logs show failures in the last 24 hours?

check_endpoint

Does this integration return content, or just a status code?

find_stale_placeholders

Which functions are marked TODO and still return a hardcoded number?

audit

All of the above, in one prioritised report

Two design decisions worth calling out:

Recent errors only, tail only. Scanning whole log files resurfaces failures that were fixed weeks ago and turns the report into noise you learn to ignore. Only recently-modified files are read, and only their last lines.

Payload over status code. check_endpoint takes a JSON path — data, result.accounts — and treats an empty collection there as critical. This is the check that catches a disconnected integration, which presents itself as a perfectly healthy HTTP 200.

Install

uvx --from automation-health-mcp automation-health

Or add it to your MCP client configuration:

{
  "mcpServers": {
    "automation-health": {
      "command": "uvx",
      "args": ["--from", "automation-health-mcp", "automation-health"]
    }
  }
}

Requires Python 3.10+. macOS reads launchd; Linux reads systemd.

Use it from an agent

Audit /var/log with job prefix "com.acme." and code in ~/src/api.

Check whether https://api.example.com/v1/accounts still holds live accounts —
the JSON path is "data".

Use the checks directly

The check layer has no MCP dependency, so it also works as a plain library — in a cron job, a CI step, or a health endpoint:

from automation_health import checks

findings = (
    checks.failing_jobs("com.acme.")
    + checks.log_freshness("/var/log/acme", max_age_hours=26)
    + checks.recent_errors("/var/log/acme")
)

for f in findings:
    print(f.severity, f.subject, f.detail)

The part that actually matters

The checks are the easy half. The half that decides whether any of this works is where the findings go.

I had a monitoring script before any of this. It ran daily, correctly detected that my main plan file was eleven days stale, and wrote that finding to a log file. Nobody reads log files. I had built a smoke detector and installed it in a room I never enter.

A detector whose output nobody consumes is not a detector. It is a diary.

So route the output of audit somewhere unavoidable: a Slack channel, the top of a dashboard, a file that gets injected into your agent's context at the start of every session. Push, not pull.

The question to ask about any automated system is not "is it running?" It is:

"If this stopped working tonight, how exactly would I find out?"

Development

uv run --with pytest --with "mcp[cli]" python -m pytest tests/ -q

Licence

MIT — see LICENSE.

Built by Elite Product LLC. We build and stabilise automation systems for companies: integrations, AI agents, and the reliability layer that tells you when they quietly stop working.

Available Tools

7 tools
auditA

Run every check and return one prioritised report.

This is the tool to call first. It answers: what on this machine is broken right now and nobody has been told?

Inputs: log_directory (required), job_prefix, code_directory, max_log_age_hours. Returns: object

check_endpointA

Check an integration by its payload, not its status code.

Set require_json_path to the part of the response that proves the integration is alive — for example "data" for a list of connected accounts. An endpoint returning HTTP 200 with an empty list is a disconnected integration, and this is the check that catches it.

Inputs: url (required), headers, require_json_path, require_non_empty. Returns: result

check_log_freshnessA

Report logs that have not been written to recently.

A daily job whose log is 26 hours old has not run. This is the cheapest liveness check available and it requires no instrumentation.

Inputs: directory (required), pattern, max_age_hours. Returns: result

check_recent_errorsA

Scan the tail of recently-written logs for error signatures.

Only recent files and only their last lines, so that failures fixed last week do not keep reappearing in the report.

Inputs: directory (required), tail_lines, within_hours. Returns: result

find_failing_jobsA

Return only the scheduled jobs whose last run exited with an error.

Inputs: prefix. Returns: result

find_stale_placeholdersA

Find functions marked TODO that still return a hardcoded value.

Catches the reporting function that reads its input file, ignores it, and returns the constant it was seeded with during development.

Inputs: directory (required). Returns: result

list_jobsA

List scheduled jobs (launchd on macOS, systemd on Linux) with exit status.

Args: prefix: only return jobs whose label starts with this string, e.g. "com.mycompany." to skip the operating system's own jobs.

Inputs: prefix. Returns: result

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.9/5.0

    Scored across 7 tools

    Disambiguation4/5

    Mostly distinct purposes: list_jobs lists, find_failing_jobs filters, check_log_freshness and check_recent_errors both target logs but with different focus (staleness vs errors), and audit is an umbrella. check_log_freshness vs check_recent_errors could cause some confusion since both deal with recent log analysis, but their descriptions are clear enough.

    Naming Consistency4/5

    Consistent verb_noun pattern: list_jobs, find_failing_jobs, check_log_freshness, check_recent_errors, check_endpoint, find_stale_placeholders, audit. The verbs vary somewhat (list/find/check/audit) but all follow the same shape and audit as a single verb is a reasonable deviation as the umbrella command.

    Tool Count5/5

    Seven tools is a well-scoped set for a system health/automation monitoring server. Each tool covers a distinct monitoring concern: jobs, logs, endpoints, placeholders, and a meta-tool that aggregates. No bloat, no obvious filler.

    Completeness4/5

    The surface covers the main health-monitoring concerns: job listing, failure detection, log freshness, log error scanning, endpoint verification, and placeholder detection, plus an aggregate audit. Minor gaps exist (e.g., no tool to trigger or retry a job, no alerting mechanism exposed), but the core monitoring workflow is complete.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      D
      maintenance
      MCP server for running infrastructure health checks with TIBET provenance. It enables users to define, execute, and audit process health checks with dependency chaining and drift tracking.
      6
      MIT
    • F
      license
      Not graded
      quality
      D
      maintenance
      MCP server for orchestrating Windows system auditing tools, supporting system checks, configuration adjustments, and security operations via a standardized interface.
      -
    • A
      license
      A
      quality
      C
      maintenance
      An MCP server that automatically discovers API endpoints from any codebase, generates and runs tests, and produces per-role QA audit reports in PDF and XLSX.
      10
      753 npm
      MIT