Use Bobbin from your agent

Updated

Bobbin exposes an MCP server, so an agent can read what a provider sent and queue a replay without you opening the browser. The tools are split across two paths:

Path	Tools	Effect
`/mcp`	`endpoints`, `captures`, `delivery_status`	Read only
`/mcp/write`	`replay_capture`	Queues a delivery

Connect through Scalpels

Bobbin accepts delegated MCP requests from Scalpels. Install the Scalpels MCP server in your agent harness and create a token with the Call installed apps ability, as described in Use Scalpels from your agent. Your agent can then list the products your team runs, pick your Bobbin deployment and call its tools. Each call is made as you; see Console for how Scalpels identifies you to the deployment.

Delegated calls do not depend on the Bobbin team membership described in Getting started; that membership matters for the browser screens.

Tools

Every list tool returns items, next_cursor, has_more and limit. limit is 1 to 100 and defaults to 25. To get the next page, pass next_cursor back as cursor with the same other arguments; a cursor from a different query is rejected with invalid_cursor. Unknown arguments are rejected.

endpoints

Lists your endpoints. Each item has id, name, retention_days, redacted_header_names, body_redaction, active_destination_id and destination_state (ready, missing, or conflict when more than one destination is active). Destination URLs are never returned.

captures

Lists the captures for one endpoint, oldest first. Requires endpoint_id.

Each item has id, method, headers, body, body_encoding, body_redacted and received_at. Query strings are never returned. Bodies that are not valid UTF-8 are returned Base64-encoded with body_encoding set to base64.

Redaction is applied twice: values redacted when the capture was stored stay redacted, and the endpoint's current redaction settings are also applied to the response. So adding a header to the redaction list hides it from the agent even in captures stored before the change, although those captures still hold the original value in Bobbin's database and browser screens.

delivery_status

Lists deliveries for one endpoint, oldest first. Requires endpoint_id; optionally narrow by capture_id, destination_id and statuses (any of queued, running, succeeded, failed).

Each item has id, capture_id, destination_id, status, attempt_count, response_status, last_error, started_at and completed_at.

replay_capture

Queues one capture to one destination. All four arguments are required:

endpoint_id, capture_id and destination_id, which must belong together, and the destination must be the endpoint's active one (take it from endpoints);
idempotency_key, 1 to 128 characters from A–Z, a–z, 0–9, ., _, : and -.

Outcomes:

Outcome	Meaning
`accepted`	The delivery is recorded and will be sent. Returns a `delivery` with its `id` and `status`. This does not mean the destination has received it yet.
`already_accepted`	This key was already used for this exact replay. Returns the original delivery; nothing new is sent.
`in_progress`	Another call with the same key is being processed right now. Retry shortly.
`refused`, reason `not_found`	The endpoint, capture or active destination does not exist or does not match.
`refused`, reason `idempotency_conflict`	The key was already used for a different replay. Use a new key.
`outcome_unknown`	The database could not confirm whether the replay was recorded. Check `delivery_status` for the returned `delivery_id` before trying again.

Use a fresh key for each replay you intend, and reuse the same key when retrying a call whose answer you did not receive. Follow up with delivery_status to see whether the destination accepted it; the retry and delivery rules are the same as for the Queue replay button and are described in Replaying captures.