MCP 2.0 Events: where does the time go after a webhook is accepted?

GPT builders Plugins / Actions builders
,
1

I’m testing MCP 2.0 Events with an IRC bridge. A mention in IRC triggers an event for a dot agent, which replies through an MCP send_message tool. I compared the IRC server timestamp, MCP service diagnostics, the dot agent’s reported markers, and WeeChat’s displayed reply time.

All times below are UTC on 2026-10-02.

Time Event Source
14:53:46.746 I posted a message addressing the dot agent. IRC server timestamp
14:53:46.784 The MCP service captured it. MCP service diagnostic
14:53:46.786 The mention event was queued. MCP service diagnostic
14:53:46.788 Webhook delivery started. MCP service diagnostic
14:53:47.231 The callback returned HTTP 200. MCP service diagnostic
~14:53:59 First visible wake marker. Dot agent’s report; approximate
By ~14:54:07 Event payload visible to the dot agent. Dot agent’s report; approximate
14:54:25.082 The MCP send_message call completed. MCP service diagnostic
14:54:25 The reply appeared in IRC. WeeChat display, rounded to seconds

The MCP service captured the IRC message in 38 ms and received HTTP 200 from the callback 485 ms after the message’s server timestamp. The reply appeared about 38 seconds after the original message, with 37.9 seconds between callback acceptance and the send tool call.

The dot agent’s wake and payload markers are its own impressions, not platform scheduler timestamps. HTTP 200 tells me the webhook was accepted; it does not tell me when the task was scheduled or began running.

Are there developer-visible timestamps for callback accepted → task started → event context available → first tool call? I’d like to distinguish scheduling time from agent processing time before drawing conclusions from this run.

My initial feelings is that reactivity from events is natuarally limited, and i’ve tested the slack integration and see some of the same, but not quite as bad. I feel that this makes sense, because a plugin shouldn’t have the same level of control over the agent as direct communication from the user, but I do think that hampers events and reveals a design issue that events have no way to help the agent understand how urgency an event should be processed by the agent.

2

Hi @toppk, did you find a cause or a reliable fix for the delay? We’re seeing similar latency with a custom Watch/iPhone bridge that sends MCP Events to our existing dot. In paired iPhone/watchOS simulator tests, two runs took about 270 and 303 seconds from the app’s send handler to the displayed reply, while submission to server-side event creation took about 2 seconds. The largest observed gap was between event creation and the payload becoming visible in the main conversation, but that interval includes scheduling, tool waits and observation, so we can’t call it pure platform queueing. Did batching or payload delivery turn out to be involved, and have you found anything that consistently improves it? Happy to compare follow-up findings here.

3

Sorry no updates on my side. I’ve even seen 30 minutes of delay, that correlated with some outage of my dot. I use the dot to try to understand the internals, but it’s pretty much a black box. I’m guessing that this is somewhat intentional and somewhat growing pains, but it would be nice if openAI had someone from their developer relations team explain what’s going on here.