automation-health-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@automation-health-mcp Audit all cron jobs for failures"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 valueWhy 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 quietlya publishing integration returned
HTTP 200while holding zero connected accountsa report had been renamed
.DISABLEDduring debugging and never renamed backa 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 |
| What is scheduled on this machine, and what did it exit with? |
| Which scheduled jobs are failing right now? |
| Which daily jobs have produced no output in over a day? |
| Which logs show failures in the last 24 hours? |
| Does this integration return content, or just a status code? |
| Which functions are marked TODO and still return a hardcoded number? |
| 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-healthOr 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/ -qLicence
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 toolsauditA
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
Scored across 7 tools
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.
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.
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.
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
Related MCP Connectors
An MCP server that automatically collects feedback on your MCP server.
Independent trust scores, tool surfaces and change history for MCP servers.
Weekly scans of MCP servers for availability and consistency, with a public dashboard.
MCP Spec Compliance MCP — audits any MCP server.json against the official Model Context Protocol
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP 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.6MIT
- FlicenseNot gradedqualityDmaintenanceMCP server for orchestrating Windows system auditing tools, supporting system checks, configuration adjustments, and security operations via a standardized interface.-
- AlicenseAqualityCmaintenanceAn 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.10753 npmMIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that audits ERC-8004 agent registrations, diagnosing issues and providing fix lists.-