@curiouskitty Great question. This is exactly the same rabbit hole I went down after the initial “task done” notification.
Biggest time sink in order:
Waiting for human input. The agent needs a yes/no decision and sits there. Worse than task completion is because a blocked agent is burning context doing nothing.
Errors and blockers. Build failures, type errors, missing env vars. The agent hits the wall and you only find out 20 minutes later.
Completion of long running tasks. The real problem.
For detection, the MCP server exposes three tools:
Send notification. Sends a one-way push alert. The agent calls it when it completes a task or makes an error. Your phone is ringing.
ask_user_yes_no Sends a push notification with a query. You tap Yes or No on your phone.
wait_for_response Puts the agent on hold until your response is returned. Up to 55 seconds, retryable, your answer sticks for 10 minutes.
Key Insight: The agent decides when it is blocked, not us. We do not attempt to detect agent states from the outside. MCP tools provide a way for AI to reach you. When the cursor agent needs approval to delete a migration file, it calls ask_user_yes_no(“Delete old migration?”). Your phone is ringing. You tap “Yes” from the couch. The agent receives the response and continues. No context is returned to the IDE.
It works on Cursor, Cloud Desktop, Windsurf, Louvable, and anything else that speaks MCP because MCP is the common protocol. Same 4 lines of JSON format everywhere.
The Human in the Loop piece was the real unlock. “Task done” notifications save you 5-10 minutes per task. Decision notifications remove entire visits to the IDE.
What kind of agent workflow are you running? Glad to help you.