Skip to main content

Module queue_notification

Module queue_notification 

Source
Expand description

Shared format + parse for the <system-reminder-{token}> wrapper that the MCP proxy prepends to tool responses when surfacing pending message_queue content. The proxy emits via format_prefix; run_agent_loop (in objectiveai-api) matches via extract_tokens. Owning both in one module keeps the two ends in lockstep — a format change here updates the matcher implicitly.

The confirmation token is embedded directly in the opening tag name: <system-reminder-<UUID>>. The API delegate generates the token on every read_pending_blocks call and stashes the token → ids mapping until the run-loop sees the token in a tool message and confirms delivery. Tokens never echoed back stay in “pending” limbo and re-deliver on the next loop’s reads — that’s the robustness win over a naive ban-list-only design.

Functions§

extract_tokens
Scan one text chunk for the prefix pattern; return every captured token in document order. Typical case is zero or one match per tool message; multiple are possible (one delegate call per tool call, but the proxy could splice multiple reminders in pathological scenarios), and the regex captures all to be safe.
format_prefix
Format the wrapper opening tag the proxy prepends to a tool response when surfacing queued blocks. The token is embedded in the tag name and is opaque to the proxy — it round-trips through the agent’s tool-message text to run_agent_loop’s confirmation scan.
format_suffix
Format the matching closing tag. The token is embedded in the tag name too, so the closing tag pairs with format_prefix’s opening tag: </system-reminder-<UUID>>. The trailing blank line demarcates the wrapper from the real tool-result content that follows it.