When your agent's tool call times out but you haven't answered
paperplane_check_ask recovers an answer after your MCP client gives up on paperplane_ask — the ask itself keeps resolving on the server regardless.
paperplane_ask can legitimately take minutes — that’s the point, it’s waiting on you. But most MCP clients impose their own tool-call timeout, shorter than the timeoutSec you set. If the client’s clock runs out first, you’ll see a client-side timeout error, not the ask’s actual result.
The ask doesn’t know the client gave up
Nothing about that timeout reaches Paperplane’s backend. The ask keeps waiting exactly as configured, on the server, independent of whatever the MCP client decided to do. If you tap Approve two minutes after the client stopped waiting, the ask still resolves to answered — the client just never heard about it.
Recovering it
// paperplane_check_ask
{ "channel": "Builds", "messageId": "msg_8a2f..." }// → non-blocking read, any time after
{ "status": "answered", "optionId": "approve", "answeredBy": "<username>" }paperplane_check_ask is a plain read — no polling, no wait. Call it with the messageId from the original paperplane_ask call (visible in your own conversation, or found via paperplane_list_messages) and you get whatever the ask has resolved to right now: pending, answered, or timeout.
The practical rule
Set timeoutSec shorter than you’d like to wait, not as long as you can stand — a client-side timeout is worse than a slightly early timeout status, because a client timeout gives you no result to act on at all. If you don’t control the client’s own limit, keep paperplane_check_ask as your fallback path rather than re-asking, which would send a second notification for the same decision.
Paperplane currently sends no MCP progress notifications on a pending ask, so a client that extends its own timeout on progress updates gets no help here — plan around the hard timeout, not around progress.