feat(js/plugins/mcp): Support for tool.v2

[ifielker]

Checklist (if applicable):

• PR title is following https://www.conventionalcommits.org/en/v1.0.0/
• Tested (manually, unit tested, etc.)
• Docs updated (updated docs or a docs bug required)

[gemini-code-assist]

Code Review

This pull request introduces support for multipart tools within the Model Context Protocol (MCP) plugin, enabling tools to natively return rich media such as images. Key changes include updating the MCP SDK to version 1.29.0, refactoring tool creation logic to support both standard and multipart responses, and adding comprehensive tests and a dedicated test application for these new capabilities. Additionally, the PR includes bug fixes for Gemini tool response conversion and error regex matching. Review feedback identifies a bug in the client.callTool invocation where the schema is incorrectly passed as the second argument and suggests enhancing error handling by pushing messages to the history queue to allow the LLM to attempt corrections.

[gemini-code-assist]

The implementation of createDynamicTool contains a bug in the client.callTool invocation and violates repository rules regarding error handling and code structure.

1. Bug: client.callTool is being passed CallToolResultSchema as its second argument. In the MCP SDK, the second argument is for RequestOptions. The parameters should be part of the first argument object.
2. Error Handling: Per repository rules, when a tool fails (result.isError), instead of returning an error object, a message should be added to the history queue to inform the LLM of the error and return control, allowing the LLM to attempt a correction.
3. Code Structure: While refactoring duplication is good, ensure that merging the logic for ToolAction and MultipartToolAction does not violate the rule against merging functions that handle different types expected to evolve separately.

The suggested code fixes the SDK call and implements the required error handling flow.

): ToolAction | MultipartToolAction {
  const config = {
    name: params.serverName + "/" + toolDef.name,
    description: toolDef.description || "",
    inputJsonSchema: toolDef.inputSchema as JSONSchema7,
    outputSchema: z.any(),
    metadata: { mcp: { _meta: toolDef._meta || {} } },
    ...(params.multipart ? { multipart: true } : {}),
  };

  const t = tool(config, async (args, { context }) => {
    logger.debug(
      "[MCP] calling tool " + params.serverName + "/" + toolDef.name
    );
    const result: unknown = await client.callTool({
      name: toolDef.name,
      arguments: args,
      _meta: context?.mcp?._meta,
    });

    if (isCompatibilityCallToolResult(result)) {
      const output = params.rawToolResponses ? result : result.toolResult;
      return params.multipart ? { output } : output;
    }

    if (isCallToolResult(result)) {
      if (params.rawToolResponses) {
        return params.multipart ? { output: result } : result;
      }
      if (result.isError) {
        context.history.push({
          role: "user",
          content: [{ type: "text", text: "Tool error: " + toText(result.content) }]
        });
        return;
      }
      const output = processResult(result);
      if (params.multipart) {
        return {
          content: result.content.map((p) => fromMcpPart(p)),
          output,
        };
      }
      return output;
    }

    return params.multipart ? { output: result } : result;
  });
  (t as any).attach = (_: any) => t;
  return t;
}

References

1. When a tool fails, instead of throwing an error or returning a ToolResponse, add a message to the history queue to inform the LLM of the error and return control, allowing the LLM to attempt a correction.
2. Do not merge functions with identical implementations if they handle different types that are expected to evolve separately in the future.

[ifielker]

decided to do it a different way.