fix(adk): keep the agent running when an MCP server becomes unreachable

[TigerkidYang]

Problem

When one configured MCP server is unreachable, every task of every agent that references it ends in FAILED before the model is called, and nothing at error level explains why after startup. Cause: the ADK MCP toolset lists tools lazily on every invocation, so a failing ListTools fails the whole tool-collection step. Reproduced locally with a 500-returning MCP backend: task FAILED, zero LLM calls, only the one startup-time failed to classify MCP tools log.

Follow-up to the discussion on #2551, where the reporter confirmed the remaining scope after 0.10.0: an error-level log for the failure, and keeping the last known tool list so a dead backend degrades like a filtered tool instead of taking the agent down.

Fix

mcpAppToolset.Tools now wraps the inner toolset's failure:

• logs it at error level on every affected invocation, with url, toolset and the underlying error;
• returns the last successfully listed tools (or none, if the server was never reachable) with a nil error, so the agent keeps running. The model still sees the tools and gets a tool error when it calls one, the same way the Python runtime's ConnectionSafeMcpTool already handles call-time connection errors;
• still surfaces a cancelled or expired invocation context as an error, so shutdown/timeouts are not masked.

initializeToolSet passes the server URL through for the log line. No changes to the classification / lazy-fallback path.

With this change the same repro completes: the model is called, the task ends COMPLETED, and the log shows MCP server unreachable and its tools were never listed; continuing without them url=http://….

Tests

mcp_ui_degrade_test.go:

• live server → tools listed, server closed → the last known list is returned with no error and an ERROR log naming the URL;
• server never reachable → empty list, no error, ERROR log;
• cancelled context → error propagated.

go vet and go test ./adk/pkg/mcp/ pass, including the existing TestInitializeToolSetRecoversWhenServerStartsAfterInitialization.

Notes

• Degrading rather than failing is the default here because that is what the reporter asked for and because one dead backend should not take out unrelated tools. If you would rather keep the failure and only add the log, that is a small reduction of this PR; happy to do it.
• The Python runtime's KAgentMcpToolset.get_tools still raises when the server cannot be listed; I left it out to keep this PR to the Go runtime the issue was reported on, and can follow up there if wanted.

Fixes #2551

---

Prepared with Claude Code assistance; the diff was reviewed and the tests above were run locally before opening the PR.

🤖 Generated with Claude Code