A hands-on lab designed around the 5 things that actually go wrong
Working back from support tickets to SA enablement.
SAs don't need to learn MCP. They need to learn what breaks in MCP deployments and how to handle it in front of a customer.
A 90-minute lab where SAs experience the 5 most common MCP failure modes with their own hands — so the first time they see each one is in a safe room, not in front of a customer.
Every section of the lab exists to make the SA experience, diagnose, or explain one of these.
"Explain MCP to a VP in two sentences. No 'protocol.'" Then name the 5 failure modes they'll experience.
SAs build a working MCP server from a starter template. They write the tool definition and handler. Anatomy learned through building. Encounter: vague description (silent failure) and context overflow (no size limit).
The aha moment: it works. Then deliberately break it three ways. Admin token — restricted docs appear. Host compatibility — same server, different behavior. API drift — silently empty results.
Grounded in the failure they just experienced. Four CISO questions, memorized by the end. Exercise: write a 3-sentence answer to "Is this secure enough for our regulated environment?"
One scenario done well: technical buyer evaluating MCP vs custom RAG. Peer feedback on 4 criteria. Close: "Name the 5 failure modes."
Working MCP server wrapping a search API. 80 lines, Node.js, zero dependencies.
User asks question ──► MCP Host ──► MCP Server ──► Search API ──► Permissioned results ──► AI answers
| Demo Step | What Happens | Failure Mode |
|---|---|---|
| 1. The Win | Search "remote work policy" → 3 clean results, permission-aware | — |
| 2. Admin Token | Switch to admin token → CONFIDENTIAL docs appear | Mode 3 |
| 3. Fix | Switch back to user token → restricted docs gone | — |
| 4. API Drift | Change API format → "No results found" (silently broken) | Mode 5 |
→ Switch to MCP Inspector for live demo
| Failure Layer | Example | Self-Resolvable? |
|---|---|---|
| 1. Tool Description | LLM ignores the tool — vague description | Yes |
| 2. Response Size | Context overflow — no pageSize limit | Yes |
| 3. Authentication | Admin token in production — permission leak | Yes |
| 4. Host Compatibility | Works in Claude, breaks in Cursor | Yes |
| 5. Permissions | Source-system ACL mismatch | Escalate |
If SAs can self-resolve layers 1–4, engineering only sees layer 5. The exact reduction depends on internal support data — but the structural logic is clear: most MCP support tickets are field-resolvable with the right diagnostic training.
Three audiences, three adaptations of the same lab.
| Section | SA | CSM / AIOM | Support |
|---|---|---|---|
| Build | Hands-on coding | "Map It" exercise — scope MCP for customer scenarios | Same build — must understand code to troubleshoot |
| Break | 3 failure modes | Watch demo, explain to a partner | 5 failure layers — trace failed requests |
| Secure | 4 CISO questions | Write 3-sentence CISO email | Permission Escalation Lab |
| Sell | Technical buyer pitch | QBR expansion + renewal framing | Escalation Decision Lab — 5 tickets, self-resolve vs escalate |
| Artifact | SA Readiness Guide | Customer Conversations Card | Diagnostic Decision Tree Poster |
The MCP lab is one module in a complete SA onboarding curriculum. Same pattern replicates across every topic.
| Level | What | Signal |
|---|---|---|
| Activity | Did they complete the lab? | Completion rate |
| Behavior | Are SAs demoing MCP in customer calls within 30 days? | CRM notes / Slack poll |
| Outcome | Are customers requesting MCP integrations after SA conversations? | Pipeline attribution |
If behavior is flat, the lab needs redesign — not more training.
When technical enablement is built as infrastructure, not content:
New team members ramp faster — the readiness guide tells them exactly what to know, what to demo, and what to watch for.
The demo prototype is annotated line-by-line — anyone can understand it, modify it, and present it without the original builder in the room.
The presentation framework is reusable across product areas — swap the content, keep the structure. Builder of builders.
The product keeps getting deeper, so the field has to keep getting sharper. Enablement systems should be built from the moments where the burden is highest — and scale from there.