We built a custom AI Agent skill, "Ark Rock Ops," so Claude can triage Rock issues for us the way a second admin would: read the exception log, check job health, and look at the web server itself. It has changed how fast we find and fix problems, and none of it is specific to The Ark.

Seven of those tools would help any organization running Rock, and we would like the core team to consider shipping them (or something like them) as a built-in administration skill. Four of the seven are built on `{% execute %}`, which we understand is being retired in an upcoming release, so this implementation is not a long term solution unless I convert it into a plugin. 

Every tool below is **read-only** — none of them changes anything in Rock or on the server. The C# tools take validated numeric and boolean parameters only

List Exception Groups

• Groups recent exceptions by type and description, with counts, trend, and a sample Id for drill-in.
• Merges errors that differ only by an Id, number, or Guid, so one bad block shows up as one line instead of 400.
• Flags what is new versus what was already there, which is the whole question after an upgrade or a deploy.
• Turns "the exception log is 2,000 rows" into a list a person can actually read.

Get Exception

1. Full detail of a single exception: the inner-exception chain, the page, the blocks on that page, and how often it has fired lately.
2. The innermost link in the chain is usually the real cause, and it is the part the summary view hides.
3. Gets an agent from "something is failing" to a named block or template in one call.

Get Job Health

1. Lists active scheduled jobs whose last run did not succeed, with last status, last success, duration, cron, and the status message.
2. Answers "is anything quietly failing" without clicking through the job list.
3. Catches the jobs that have been broken for months and nobody noticed.

Get Server Health

1. Snapshot of the web server: process memory, managed heap, GC counts, thread pool, app uptime, OS uptime, machine RAM, disk space, and the IIS log folder.
2. App uptime alone answers "did the app pool recycle," which is the first question in half of our incidents.
3. Separates "Rock is slow" from "the server is out of memory or out of disk."

Get IIS Summary

1. Summarizes the site's IIS log for the last N hours: status code mix, top 5xx, top 404s, slowest paths with average and max time, bots, and an hourly breakdown.
2. Shows errors visitors hit that Rock never logged as exceptions.
3. Finds the crawler or scanner that is driving load, and the pages that are genuinely slow rather than the ones people complain about.

Get IIS Lines

1. Returns the raw log lines from a few seconds around one moment, filtered by status class or path.
2. Names the actual request behind an exception Rock recorded without request details.
3. Masks tokens, keys, and similar values in the query string and referrer before returning anything.

Get Windows Events

1. Recent errors (and optionally warnings) from the Windows Application and System logs, grouped by source and event Id.
2. Optionally includes IIS worker recycle events and the reason for each — scheduled, memory limit, configuration change.
3. Covers the failures that never reach Rock at all: app pool crashes, .NET runtime faults, disk and service problems.

Rock already stores the evidence; it is just spread across the exception log, the job list, the server, and two Windows logs, and reading it takes an administrator who knows where to look. Giving the agent read-only access to all five turns a morning of digging into a few minutes, and it means a smaller church without a full-time Rock admin gets the same triage a larger one does.

MCP-Tools.jpeg