### backend platform (enabled)
- **Use for**: backend protocol scenarios (HTTP / gRPC / GraphQL / WebSocket / DB).
- **Server**: `backend-devtools` · **scenario tools**: the `bedt_scenario-*` tools
  (`bedt_scenario-add` / `-update` / `-delete` / `-list` / `-search` / `-run`).
- **Store**: project → `.ironbee/scenarios/bedt`, global → `~/.ironbee/scenarios/bedt` (the
  server's `SCENARIOS_DIR`; you pass `scope`, the server resolves the path).
- Scenario **scripts** call this platform's tools via `callTool('<bare-tool>', {...})` — discover
  the available `bedt_*` tool names from your connected MCP tool 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, …).