### Backend platform (enabled)
- **Use for**: backend protocol scenarios (HTTP / gRPC / GraphQL / WebSocket / DB).
- **Server**: `backend-devtools` · **scenario tools**: `mcp__backend-devtools__bedt_scenario-*`.
- **Store**: project → `.ironbee/scenarios/bedt`, global → `~/.ironbee/scenarios/bedt` (the server's
  `SCENARIOS_DIR`; pass `scope`, the server resolves the path).
- Scenario **scripts** call backend tools via `callTool('<bare-tool>', {...})` — discover the
  available `bedt_*` tool names (request http/grpc/graphql/websocket, log, db, o11y …) from your
  connected MCP schemas; don't guess.

**What to test & how — capture the SAME evidence the verifier would** (a scenario runs FOR
verification, so its script must collect what the backend cycle collects). At least ONE evidence path
is required — in the script, exercise one+:
- **Protocol-call** — `bedt_request_http` / `bedt_request_grpc` / `bedt_request_graphql` /
  `bedt_request_websocket-open…` / `bedt_request_replay`; inspect the response `status` / body /
  headers (4xx/5xx and gRPC non-OK are NORMAL results, not transport errors — decide pass/fail by what
  the task requires). Chain POST→GET to confirm side effects.
- **Log-evidence** — `bedt_log_register-source` then `bedt_log_read` / `bedt_log_read-multi` /
  `bedt_log_follow` (filter by level / pattern / trace-id) when an external driver hits the endpoint.
- **DB-evidence** — `bedt_db_connect` (read-only by default) then `bedt_db_query` /
  `bedt_db_describe-table` / `bedt_db_snapshot` + `bedt_db_diff` to inspect state after a migration /
  write.

`return` the responses / log lines / rows (capture each read with `returnOutput: true` so the data
reaches the script's `return`) **plus explicit pass/fail assertions** so a later verify run can judge
them. Runtime-agnostic —
works for any backend language (Node, Java, Python, Go, Rust, Ruby, .NET, …).