receive_response() streams tool results as UserMessage, causing agent loops

[srinathh]

Problem

receive_response() streams MCP tool results as UserMessage containing ToolResultBlock, indistinguishable from real user messages without inspecting the content blocks. This makes it easy for the model to misinterpret tool results as new user input, causing infinite agent loops.

Reproduction

When using create_sdk_mcp_server to register a custom MCP tool (e.g. send_message), the receive_response() stream looks like:

AssistantMessage  → [ToolUseBlock(name='mcp__clawless__send_message', ...)]
UserMessage       → [ToolResultBlock(tool_use_id='...', content='Message sent')]
AssistantMessage  → [ToolUseBlock(name='mcp__clawless__send_message', ...)]  # agent loops
UserMessage       → [ToolResultBlock(...)]
... repeats indefinitely

The agent sees the UserMessage (tool result) and interprets it as requiring a response, calling the tool again, creating an infinite loop.

Expected behavior

One of:

1. Distinct message type: Stream tool results as a ToolResultMessage (or similar) rather than UserMessage, so consumers can differentiate without inspecting content blocks.
2. Filtered stream: Provide an option to only yield "meaningful" messages (assistant text, result) and handle tool round-trips internally.
3. Documentation: At minimum, document that UserMessage in the stream may contain ToolResultBlock and is not always a real user message.

Workaround

We worked around this with:

• System prompt instructions explicitly telling the model that tool results are not user messages
• Content validation in the tool handler (rejecting trivially short messages)
• Per-turn rate limiting on tool calls

These are defense-in-depth but the root cause is the ambiguous message typing.

Environment

• claude-agent-sdk (Python)
• MCP tools via create_sdk_mcp_server

[m13v]

we hit the same infinite loop pattern building a tool execution layer. the root issue is that when the model sees a UserMessage after its own ToolUse response, it interprets it as a new conversational turn rather than the completion of its tool call. our fix was adding a stop condition in the loop that checks whether the last assistant message was a text-only response (no ToolUse blocks). if the model responds with just text after a tool result, the loop ends. if it responds with more ToolUse blocks, the loop continues. this prevents the model from treating tool results as prompts while still allowing multi-step tool chains. the system prompt approach helps but is fragile because models sometimes ignore it under high context pressure.

[m13v]

our tool execution layer that handles the tool call loop, stop conditions, and retry logic: https://github.com/m13v/fazm/blob/main/Desktop/Sources/Providers/ChatToolExecutor.swift

and the Claude API integration that manages the message flow between tool results and assistant responses: https://github.com/m13v/fazm/blob/main/Desktop/Sources/Providers/ChatProvider.swift