fix(mcp): refuse MCP tools that shadow reserved framework names

[sushant-me]

Fixes #1513

Problem

McpToolset accepted any tool name an MCP server advertised. Names that the
ADK framework reserves for its own built-ins were therefore installable by a
remote server, and the duplicate-name guard in
LlmRequest.Builder.appendTools never noticed:

• In-model built-ins (google_search, google_maps, url_context,
  vertex_ai_search, code_execution) are appended only to the request's
  config.tools and are never placed in the tool map, so they never collide
  with the MCP entry.
• set_model_response is consumed internally by
  SingleTurnAgentExecutor/LlmFlow; a server tool of that name makes the
  flow abort the whole run where it expects its own response model.

The result is that an MCP server silently wins dispatch for a framework tool
name — a tool-boundary bug, not a naming nit.

Fix

Reserve the names in McpToolset.getTools() and fail loading with
McpToolLoadingException when a server advertises one:

private static final Set<String> RESERVED_TOOL_NAMES = Set.of(
    "set_model_response", "transfer_to_agent", "google_search", "google_maps",
    "url_context", "vertex_ai_search", "code_execution", "load_artifacts",
    "loadMemory", "exit_loop", "list_skills", "load_skill",
    "load_skill_resource");

Correction (later push). An earlier revision of this PR listed the Go set
verbatim, which was wrong in both directions.

• finish_task and task_completed do not exist anywhere in this port. They
  were refused as collisions against tools this framework does not have.
• The memory tool is named loadMemory here, not load_memory. This port takes
  a tool's name from the method name when the method carries no
  @Annotations.Schema — LoadMemoryTool#loadMemory annotates only its
  parameter — so the other ports' load_memory spelling did not match, and the
  guard was not watching for the name it actually uses.

Two tests now pin this: getTools_refusesDerivedLoadMemoryName, and
getTools_acceptsNamesOtherPortsDefineButThisOneDoesNot, which asserts that the
three names from the other ports are accepted rather than refused.

McpToolLoadingException is used deliberately: retryWhen treats
IllegalArgumentException as fatal, and a config error of this kind should
surface once rather than be retried as a transient server fault.

Tests

getTools_refusesReservedToolName mocks an McpSyncClient returning
McpSchema.Tool.builder().name("google_search") and asserts the load fails
with McpToolLoadingException. It also verifies the client is called exactly
once, pinning the no-retry behaviour.

Verified in both directions:

• without the change to McpToolset.java: Tests run: 1, Failures: 1
• with the change: green

This mirrors the equivalent google/adk-go fix in #1606.

Why a list at all, and why I would rather not keep one

This is the second correction to RESERVED_TOOL_NAMES, and the reason is the
approach rather than either edit. The set was assembled from names reported one
at a time, so each fix addressed the name in front of it and left the rest. Only
after enumerating the tools this framework actually declares — rather than
transcribing a list — did the remaining four appear.

The structural alternative is better and I would rather implement it: give the
in-model tools their name in the request's tool map, so the existing duplicate-name
check in LlmRequest.appendTools refuses a server that takes one. That guard
already exists and already has the right semantics; the in-model tools currently
bypass it by appending only to the config tools. A list needs maintaining on every
tool the framework adds, and its completeness is not checkable by the same
mechanism that uses it.

If you would rather have the list, it is here and tested. If you would rather have
the guard apply at the point where names are already being checked, I am happy to
rework it that way instead.

[hemasekhar-p]

Hi @sushant-me , thank you for your contribution. We appreciate you taking the time to submit this pull request. Currently this PR is under review by our team, we will keep you posted if any additional information is required. thank you.

[sushant-me]

One scoping note on the residual, so the trade-off is on the record — the same class of note as the one on the Go port, but the reasoning differs here and I did not want to copy it across.

This guard closes the path where a remote MCP server advertises a reserved name. It does not change the underlying property that an in-model tool never occupies its name in the tool map:

• GoogleSearchTool.processLlmRequest (and the other in-model tools) only append to configBuilder.tools(...); they never put the name into llmRequestBuilder.tools().
• Nothing else does either — I could not find a duplicate-name check at the tools() map level in the flows (the only duplicate check is for sub-agent names in BaseAgent).

So an in-process tool registered under google_search — a FunctionTool or an AgentTool — is accepted alongside the in-model tool. In this repository that requires the application author to pick the name, so I treated it as a footgun rather than the adversarial case and kept this PR to the server-controlled path.

Where Java differs from Go: in adk-go the equivalent map is map[string]any and consumers type-assert to tool.Tool, so occupying a name with a sentinel breaks them — that is why I left the general fix alone there. Here LlmRequest.tools() is already Map<String, BaseTool> (LlmRequest.java:89), so registering a sentinel or a real holder under the in-model name is type-safe. The open question is only whether a sentinel value is acceptable to advertise, which is a design decision rather than a typing constraint.

Happy to prepare that broader change if you would prefer the invariant enforced in one place instead of at each boundary — it touches high-fan-in classes, so I did not want to fold it in unasked.