Interrupt recovery and MCP tool errors should be cleaner

[bnovik0v]

Problem

There are two related cleanup problems around tool calls.

1. Interruption does not fully clear stale tool-call state

If a bad tool-call lifecycle leaves stale tool still running state behind, interrupting the conversation does not fully clear that assistant-side state.

Example:

• a tool call gets stuck
• the user interrupts to recover
• assistant text state resets
• but Pipecat can still remember an old tool call as in progress

Expected behavior:

• interruption/reset should clear assistant-local tool-call tracking so recovery is clean

2. MCP failures lose the real error message

When an MCP tool call fails, Pipecat logs the real error but sends back only a generic message.

Example:

• MCP call fails with upstream unavailable
• current result is only Sorry, could not call the mcp tool

Expected behavior:

• Pipecat should return a useful tool result such as:
  • Error calling mcp tool demo_tool: upstream unavailable

Why this matters

Both problems make recovery harder:

• interruption is less reliable than it should be
• the model loses the actual reason an MCP tool failed