# REPRESENTATIVE OUTPUT — authored at M8 build time; REGENERATE on the golden VM:
#   docker compose run --rm runner python app/mcp_soc_demo.py | tee expected/mcp_soc_demo_output.txt
──────────────────────── Day 4 — MCP SOC Tool-Building Demo ────────────────────────
  MCP server : http://mcp-server:8000/sse
  Ollama     : http://ollama:11434
  Model      : qwen2.5:3b

Step 1: Connecting to MCP server via SSE…
  Connected. Available tools: ['lookup_indicator', 'triage_indicators']

Step 2: SOC task submitted to qwen2.5:3b
╭─ User Task ─────────────────────────────────────────────────────────────────╮
│ During incident review we pulled three indicators from a compromised        │
│ workstation's proxy logs: the IP 198.51.100.99, the domain                  │
│ login.corp-sso-verify.example, and the IP 192.0.2.10. Triage these          │
│ indicators and tell me which ones we should act on first and why.           │
╰─────────────────────────────────────────────────────────────────────────────╯

Step 3: First Ollama call (model sees task + tool schemas)…
  (74 tokens, 3.3 tok/s)
  Model issued 1 tool call(s): ['triage_indicators']

Step 4: Calling MCP tool triage_indicators
  Args: {'indicators': ['198.51.100.99', 'login.corp-sso-verify.example', '192.0.2.10']}
╭─ MCP Tool Result: triage_indicators ────────────────────────────────────────╮
│ === IOC Triage Summary (3 indicators) ===                                   │
│ malicious=2  suspicious=0  unknown=0  benign=1                              │
│                                                                             │
│ --- Ranked (highest risk first) ---                                         │
│   [MALICIOUS ] ( 98%) login.corp-sso-verify.example  [domain]  tags:        │
│ phishing, credential-harvesting, aitm                                       │
│   [MALICIOUS ] ( 97%) 198.51.100.99  [ipv4]  tags: malware-distribution,    │
│ c2, exe-hosting                                                             │
│   [BENIGN    ] ( 88%) 192.0.2.10  [ipv4]  tags: cdn, shared-infrastructure  │
│                                                                             │
│ --- Recommended next step ---                                               │
│   ! Block/contain the malicious indicators and open an incident.            │
│   (Reputation verdicts are decision SUPPORT — a human confirms before       │
│ blocking.)                                                                  │
╰─────────────────────────────────────────────────────────────────────────────╯

Step 5: Second Ollama call (model sees tool results)…
  (198 tokens, 3.0 tok/s)

──────────── Final LLM Response (grounded on MCP tool results) ────────────
╭─────────────────────────────────────────────────────────────────────────────╮
│ Act first on login.corp-sso-verify.example (98% malicious — an active AiTM  │
│ phishing page cloning your SSO portal) and 198.51.100.99 (97% malicious —   │
│ malware distribution and C2). Recommend DNS sinkhole for the domain and a   │
│ perimeter block for the IP, pending analyst confirmation. Do NOT block      │
│ 192.0.2.10: it is a benign shared CDN node flagged as a false-positive      │
│ magnet — blocking it previously broke a vendor portal.                      │
╰─────────────────────────────────────────────────────────────────────────────╯

Tool-call round-trip complete.
Path: User → qwen2.5:3b → MCP tool (triage_indicators) → qwen2.5:3b → Answer
Now add YOUR tool in app/mcp_server.py (see the YOUR TURN scaffold), restart
mcp-server, and re-run with a question that routes to it.
