MCP Client Tool + Google Vertex AI → 400 Bad Request (schema incompatibility)

Questions
1

Hi,
I’m getting a 400 Bad Request when using the MCP Client Tool with Google Vertex AI.
Setup:

  • n8n 2.25.6 self-hosted
  • Google Vertex Chat Model (gemini-2.5-flash, europe-west4)
  • MCP Client connected to Zoho Recruit MCP server via OAuth2
    The same credentials work fine in other workflows without MCP. As soon as the MCP Client is attached as a tool to the AI Agent, Vertex throws a 400. n8n doesn’t surface the full Google error response.
    Switching to OpenAI or standard Gemini API is not an option — GDPR requires EU data residency, so Vertex AI is the only compliant option.
    Is there a fix or workaround planned?
2

Hey @Tim_Zwarthoed, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Anthony_Lee, @Pierre_R1, @Inshal_Amir - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @Tim_Zwarthoed Welcome!
The 400 is coming from the tool declarations, not the credentials. n8n passes each MCP tool’s inputSchema straight through to Vertex, and Gemini’s FunctionDeclaration schema takes type as a single value, so any property the Zoho server declares as "type": ["string", "null"] gets rejected at request validation, before the model runs. That is why it only breaks once the MCP Client is attached, and why the node shows you nothing but the status code.
Set Tools to Include to Selected on the MCP Client node and add the tools back one at a time to find which declarations Vertex refuses. For those, call the same Zoho Recruit endpoints with an HTTP Request Tool and define the parameters with $fromAI(), so Vertex only ever sees a schema you control. Everything stays in europe-west4.

On the fix itself, it is tracked internally as GHC-2086 and the issue is still open:

4

Vertex AI requires tool definitions to strictly adhere to the Google Cloud Vertex AI API specification. MCP tools, by nature, are dynamic. When the AI Agent node compiles the toolset to send to Vertex, the resulting JSON payload for the tools array contains elements (likely in the parameters object) that Vertex AI rejects as invalid, resulting in a generic 400 Bad Request before the model even processes the prompt.

Since you cannot change the MCP server or the Model, you must change how the tool is presented to the AI Agent. Instead of connecting the MCP Client Tool directly to the AI Agent, you should wrap the MCP functionality inside a Workflow Tool​.

This decouples the MCP schema from the Vertex AI request. Vertex will only see a simple “Workflow Tool” with a static schema, and n8n will handle the MCP execution internally.

Do these

  1. Create a “Tool Workflow” (The Wrapper):

    • Create a new workflow.
    • Trigger: Use the Execute Workflow Trigger​.
    • Node 1: Add the MCP Client Tool node. Configure it to call the specific Zoho Recruit tool you need.
    • Node 2: Use a Code Node or Set Node to clean up the output into a simple string or JSON object.
    • End: Return the result to the parent workflow.

  2. Configure the AI Agent Workflow:

    • Remove the direct MCP Client Tool connection.
    • Add the Workflow Tool node.
    • Workflow to Call: Select the “Tool Workflow” created in Step 1.
    • Tool Description: Be very explicit (e.g., “Use this tool to fetch candidate data from Zoho Recruit. Input should be the candidate ID.”).
    • Input Schema: Define a simple JSON schema (e.g., {"type": "object", "properties": {"candidateId": {"type": "string"}}}).

  3. Connect to Vertex AI:

    • Connect the Workflow Tool to your AI Agent.
    • Vertex AI will now only see the Workflow Tool definition, which is a standard n8n-generated schema that Vertex accepts.

You can also use LiteLLM, ​provided you are comfortable adding one more component to your self-hosted stack.

Does that help?

5

The wrapper-workflow fix works, and it’s worth knowing exactly why: Vertex’s FunctionDeclaration follows OpenAPI 3.0, where nullability is a separate nullable flag rather than a JSON Schema type union. Anything that flattens the union down to a single type plus that flag gets you past the 400 — which is what the wrapper is doing incidentally.

If you’d rather not maintain a wrapper per tool, worth testing Gemini through its OpenAI-compatible endpoint as the model node instead: different schema path, and it may accept the union as-is. Either way, Zoho Recruit emits optional fields on most of its endpoints, so expect this on more tools than the one that surfaced it.