Rung 5: Claude Code walks stop 2 through the MCP tour guide

2026-10-29, thread mcp-guide. claude -p (Sonnet) with only the qpoint-tour server (--mcp-config, --strict-mcp-config), against the lab embedded in /pages/phase4/tour-mcp on :3000. The prompt names the embedded tab's id so no one else's tab moves. Three turns: the opening prompt, then "Next." twice. The agent's text is verbatim; tool calls are listed as made.

Person

Walk me through how Qpoint covers MCP risk, using the tour on my screen. Pass tabId "tab-suqygg" on every tool call (that's my screen). Take it one step at a time: move the page, then tell me in two or three sentences what I'm looking at. Cover stop 2 (Watch, Tune, Drill) and stop there.

Agent

• list-tours {}
• tour-state {}

Stop 2 starts at s2-watch. Moving there.

• go-to-step {"stepId": "s2-watch"}
• read-step {"stepId": "s2-watch"}

Watch (stop 2, first step). You're on the detail page for the github MCP server. The five tools ringed on the page are the ones that send, delete or execute: add_issue_comment, delete_branch, delete_file, delete_repo and run_workflow. The panel says your agents have made 133 of those calls, 32 different people made them, and one tool has never been called.

The point is that a server can be sanctioned and healthy and still do damage with tools it's allowed to use. So the first job is to see what it actually does. Qpoint can already observe least privilege per tool and the transport (ASI02 #1 and ASI07 #1). It has a record of every invocation (ASI02 #8). What stays with you is why the agent picked a tool, and what GitHub's own token can do inside GitHub.

Say when you're ready and I'll move to Tune.

Person

Next.

Agent

• next-step {}
• read-step {}

Tune (stop 2, second step). Same github page, now showing the controls you'd use to tighten it. The rings mark three areas: the list of tools this server is allowed to use, the verbs that wait for a person to approve them, and a Change impact panel. Those are the two controls the model doesn't have on its own.

Change impact replays last week against the new rule. If deletes on github needed a person, 14 calls would have paused, 3 people would have been affected, and 0 would have been blocked. Nothing applies until you publish, because everything lands in the Policy Config draft.

The Stage approval at Enforce button in the panel is yours to press. It puts P-TOOL-APPROVAL at Enforce into the draft, and nothing goes live from it. I haven't pressed it. Who approves, and whether they read before they click, stays with you.

Say the word and I'll move to Drill.

Person

Next.

Agent

• next-step {}
• read-step {}

Drill (stop 2, last step). The tour is back on the home dashboard. The two dashed frames are examples floated over the real tiles. Sensitive data shows an example in place of your live 0, and findings shows one in place of your live 7. The scenario is "an agent sends a customer's SSN to an MCP server nobody approved."

Based on your settings today, two findings would be raised. The first is high severity: sensitive data sent to an unsanctioned server. Its policy, P-SENS-DETECT, is in Observe, so it detects but doesn't block. The second is medium: an unsanctioned MCP server in use. P-MCP is in Enforce, so it blocks the server. You'd get two Slack posts to #sec-alerts and one POST to your webhook. Nobody would be paged, because PagerDuty isn't connected.

Simulate violation is yours to press. It sends test messages marked as a drill to those channels and leaves your findings and evidence alone. I haven't pressed it. Who answers the alert, and how fast, is yours.

That covers Watch, Tune and Drill for stop 2, so I'll stop here. Pressing the button would move the tour to the "Drill sent" step.