Asking a question that isn't a built-in audit

The previous tutorial picked an audit from a menu. This one strips that off: you’ll ask a plain-English question that nobody pre-wrote, and watch what Claude does.

By the end you’ll have:

• A feel for when to pick from the menu and when to ask conversationally
• Seen what Claude does when no built-in fits — it looks around your Singlewire system, finds the right place to look, and asks
• Confidence that the same safety rules apply either way

You will need:

• Claude Code (or another MCP client) connected to your team’s mcsinglewire instance
• About ten minutes and a sense of curiosity

1. Ask a deliberately broad question

   Open Claude Code and ask:

   What kinds of devices does my Singlewire system know about?

   This is intentionally vague. There’s no built-in audit for it. Claude has to find out — and you can watch it work. The transcript will show Claude looking up what categories of devices Singlewire knows about, picking one (probably “Devices” or “IP Speakers”), then asking your system for a sample.

   The answer comes back as a plain-English summary — usually a count of each device type with a one-line description. Claude didn’t need to know your system ahead of time; the answer is built from a single read-only look.

2. Watch a question that needs refinement

   Now ask something where the answer might not be there at all:

   Are any of our IP speakers stuck on old firmware?

   Two outcomes are possible:

   • Singlewire reports firmware version on speakers. Claude groups speakers by version and tells you which are behind.
   • Singlewire doesn’t expose firmware on speakers. Claude tells you that, explicitly, instead of guessing a number.

   The second outcome is the important property: when the data isn’t there, you get “the system doesn’t tell me that”, not a fabricated answer.

3. Watch a write attempt get refused

   Ask Claude to change something:

   Create a new scenario called "Test alarm 2026-05-13".

   Three things happen, in order:

   1. Claude searches for “create scenario”.
   2. The call to your Singlewire system is refused before it ever leaves — the server is read-only, and changing scenarios is a write.
   3. Claude tells you it can’t, and explains why: this tool only reads from your Singlewire system, never writes to it.

   The refusal isn’t Claude being polite. It’s the server rejecting the call at three separate layers — see How it stays safe for the detail.

4. Watch a denylisted operation get refused

   Singlewire’s API has one operation — getScenario — whose description in the API documentation is ambiguous about whether it might dispatch a notification. mcsinglewire refuses it until Singlewire confirms otherwise in writing.

   Ask:

   Use getScenario to show me one of our scenarios.

   Claude tries it, the server refuses, and Claude relays a clear explanation of why and what to ask instead. The scenario_inventory built-in audit covers the same information safely.

When to reach for which

The built-in audits (Prompts) are the right move for anything you ask repeatedly — the wording is figured out once and reused, so audits compare cleanly across weeks. Ad-hoc questions are right for one-offs, exploratory questions, and follow-up drill-ins from a built-in.

What’s next

• Investigating an incident walks through a Code Blue scenario using several built-in audits in sequence plus ad-hoc follow-ups.
• Built-in audits is the full catalogue of what’s already on the menu.