Skip to main content
Glama
chainwright

automation-health-mcp

by chainwright

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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.

find_failing_jobsA

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

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.

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.

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.

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.

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?

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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

ActivityStale
ResponsivenessNo issues