feat: exclude MCP bridge tools from read-only streak detector

[kaitranntt]

Problem

The read-only streak detector in toolloop.go stops agent runs after 12 consecutive non-mutating tool calls. This guard was designed for filesystem tool loops (read_file, list_files, find) but catches MCP bridge tools in the default fallback of recordMutation().

MCP tools are user-defined external integrations (email, calendar, databases) where read-heavy workflows are expected and legitimate. A workflow like "query inbox + read 10 emails + summarize" hits the critical threshold before the agent can respond.

Current behavior

recordMutation() classifies tools into 3 buckets:

• Mutating (write_file, edit, spawn, etc.) → resets streak
• Neutral (exec, bash) → neither resets nor increments
• Everything else → increments streak

All mcp_* tools fall into "everything else" and increment the read-only streak, triggering the guard at 12 calls.

Suggested fix

Treat mcp_* prefixed tools as neutral (same as exec/bash) in recordMutation() since GoClaw cannot determine whether an MCP tool is read or write.

if toolName == "exec" || toolName == "bash" || strings.HasPrefix(toolName, "mcp_") {
    return // ambiguous — neither reset nor increment
}

Alternatives considered

• Let MCP tool schemas declare mutating/read-only (more correct but higher complexity, could be a follow-up)
• Make thresholds configurable per-agent (addresses symptom not root cause)

Affected file

internal/agent/toolloop.go line 127

[mrgoonie]

This is a valid issue. The read-only streak detector was designed for filesystem tools, and MCP tools shouldn't be caught by it since GoClaw can't know whether an MCP tool is read or write.

Your suggested fix (treating mcp_* as neutral) is the right minimal approach. The alternative of having MCP schemas declare mutating/read-only could be a follow-up enhancement.

Open to a PR if you want to take this on - it's a small, clean change in toolloop.go.