Checkmk

Setup

1. In Checkmk create an automation user: Setup → Users → Add user, tick Automation secret for machine accounts, and copy the secret. Give it the guest role for read-only access, or admin if you want the configuration endpoints.
2. Set CHECKMK_URL to your site root including the site name — https://monitoring.example.com/mysite — with no trailing slash. The site name is part of the path and leaving it out is the usual cause of a 404 that looks like a wrong version.
3. Set CHECKMK_USERNAME to the automation user and CHECKMK_SECRET to its secret.

The Authorization header is Bearer <user> <secret> — two space-separated values in one Bearer token, which is Checkmk's own scheme and looks wrong the first time you see it. The adapter assembles it.

Setup vs Monitoring. Checkmk's REST API has two halves and they answer different questions. /domain-types/host_config/… is the configuration — what has been set up. /domain-types/host/… and /domain-types/service/… are the live monitoring state — what is happening now. A question about a red service needs the second; a question about what is monitored needs the first.

Live state is queried with a Livestatus expression. The query parameter takes JSON like {"op": "=", "left": "state", "right": "2"} — state 0 is OK, 1 warning, 2 critical, 3 unknown. Combine with {"op": "and", "expr": [...]}.

Live state is read with POST. The three live-state tools (checkmk_list_host_states, checkmk_list_service_states, checkmk_list_host_services) send query and columns as a JSON body to the …/collections/… endpoints. They only read. Checkmk 2.3 introduced this form and deprecated the old GET-with-query-string variant (werks 17003 and 17512), which Checkmk's development branch has already removed, so these tools need Checkmk 2.3 or newer. Each sends a useful default set of columns; columns adds one more.

Changes need activation. Anything written into the Setup half sits in a pending-changes queue until activated. This adapter is read-only (the live-state POSTs are queries, not writes), so it never leaves a half-applied change behind.

Self-hosted, which is the thing to plan for.

• On AnythingMCP Cloud the instance must be reachable from the public internet on a real hostname with a valid TLS certificate. A self-signed certificate will fail: the connector offers no trust-anything switch, and a homelab's default certificate is exactly the case that breaks.
• On an internal host (monitoring.intern, 10.0.0.x), self-host AnythingMCP on the same network and add that host to SSRF_ALLOWED_HOSTS, or the outbound guard refuses the call before it is made.