Your first audit

You’re sitting at Claude Code with mcsinglewire already connected (your IT team or whoever set this up has done that part). This tutorial walks you through running a real read-only audit end to end and seeing it land in the audit trail.

By the end you’ll have:

Picked the Offline devices audit from the menu in Claude Code
Read Claude’s answer and judged whether anything in your fleet needs attention
Seen the call recorded — who asked, what they asked, what came back

You will need:

Claude Code (or another MCP client) connected to your team’s mcsinglewire instance
One quick login to Singlewire on first connect, and you’re set

Pick the audit

In Claude Code, type / to open the menu. Audits from mcsinglewire show up in the list — pick the one called offline_devices.

You’ll be asked for a single value: how many hours back to look. Leave the default of 24 for now (you can tighten it later when you want a shorter window).

If you’d rather skip the menu, you can just type the question yourself:
```
Which IP speakers haven't checked in over the last 24 hours?
```
Both routes do the same thing. The audit is just the pre-written version of that phrasing — it exists so the team doesn’t have to reinvent the question each time.
Read Claude’s answer

Claude will look up where IP speakers live in your Singlewire system, ask for the ones that haven’t checked in, and write up the result. A typical answer looks like:
```
Three IP speakers haven't reported in over the last 24 hours:

  • Cardiology-A-204 — last seen 2 days ago, site Main-Campus
  • ER-Bay-3        — last seen 18 hours ago, site Main-Campus
  • Cafeteria-Main  — last seen 3 days ago, site Main-Campus

Healthy: 87 / 90 speakers reporting within window.

Want me to pull last known IPs for the offline three?
```
The shape — stale list, healthy summary, optional follow-up — is the same every time, because the audit’s wording is fixed. Run it next Tuesday and you’ll get a comparable answer.
See the call recorded

Every time this tool talks to Singlewire on your behalf, a record is kept: who asked, what they asked, what came back. You don’t have to do anything to make this happen — it’s automatic.

The record never includes anyone’s login token, just a stable fingerprint of which user was logged in. So you can answer “who’s been asking what?” without the log itself becoming a credential.

The hands-on detail — where the log lives, how to filter it with jq, what each field means — is on the Read the audit log page in the operator section.
Try a tighter window

Pick the audit again, but this time enter 4 for the hours.

Your answer should be much shorter — devices that haven’t reported in 4 hours is a smaller set than the 24-hour list. A fresh line lands in the audit log for this call too.

That’s the working pattern: a fixed question, with one value you can tune.

What’s next

Asking a question that isn’t a built-in audit shows what happens when the menu doesn’t have what you need.
Investigating an incident walks through using several audits together — anchoring a Code Blue timeline, finding who didn’t acknowledge, drilling in.
Built-in audits is the full menu — fourteen audits across inventory, activity, and configuration.