Database MCP

MCP replay

Replay shows what the agent saw, what it proposed, who approved it, what the runner attempted, and what happened.

Overview

Replay is the durable inspection path for MCP database workflows. It links tool call, trusted context, source read, evidence bundle, proposal, approval or rejection, writeback job, runner receipt, and final applied/conflict/failed state.

Replay must not rerun side effects. A replay inspection returns persisted records and receipts so humans can audit the exact sequence later.

For local runner mode, replay is stored in the local SQLite store and can be exported. For Cloud mode, replay is hosted and searchable with team permissions.

Developer notes

Persist run_id, evidence_bundle_id, proposal_id, replay_id, tenant/principal, workflow/capability, business object id, and query fingerprint in app-side receipts.
Use replay handles instead of asking a model to explain what happened later.
Do not rerun external writeback during replay.
Keep raw JSON available under advanced inspection, but show a human-readable timeline first.

Local replay commands

replay.sh

corepack pnpm runner replay show wrp_123 --store ./.synapsor/local.db
corepack pnpm runner replay export wrp_123 \
  --store ./.synapsor/local.db \
  --output replay.json

Examples

text

MCP tool called
trusted context bound
external row read
evidence stored
proposal diff created
approval recorded
writeback job created
runner returned applied/conflict/failed