MCP client does not support multi-parameter MCP server: 'Cannot read properties of undefined (reading "inputType")'

[clcc2019]

Bug Description

When using n8n with the MCP client, it does not support MCP servers with multiple parameters. The following error is thrown: Cannot read properties of undefined (reading 'inputType'). Please investigate and resolve this issue.

To Reproduce

1. Configure n8n to use the MCP client.
2. Attempt to connect to an MCP server that requires multiple parameters.
3. Observe that the following error appears: Cannot read properties of undefined (reading 'inputType').

Expected behavior

The MCP client should support MCP servers with multiple parameters, and the connection should succeed without JavaScript errors.

Debug Info

Cannot read properties of undefined (reading 'inputType')

Operating System

docker

n8n Version

1.117.3

Node.js Version

22

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted

[n8n-assistant]

Hey @clcc2019,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-5362".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-5362

[MookieLian]

Thanks for reporting this issue! We've attempted to reproduce the problem, but unfortunately, we weren't able to replicate it. It's possible there was some environmental or other variable that prevented us from seeing the same behaviour.

If you're still encountering this issue, please provide any additional details or steps to reproduce it, and we'd be happy to investigate further. Thanks for your understanding!

Docker, Self-Host, Debian, Version: 1.117.3

MCP Tool connected, required two parameters(x, y) -> successful run.

#closed:cant-reproduce

[david-at-appomni]

Having the same issue I believe. Wiz MCP server, self-hosted, cannot control schema; still fails on 1.120.4

**Same behavior on 1.121.1 as well.

[david-at-appomni]

It has to do with schema validation. If I attempt to manually execute the tool, it throws the same error as above before giving you the chance to fill in any values.

However!

If you just mash the Orange Execute Button before it can finish any preflight schema validation shenanigans, it just pushes the values to the destination and gets the response.

Sadly this doesn't offer itself as a workaround since the agent will not skip those steps.

My typescript isn't very strong, but the robots think it has to do with whenever a server defines parameters whose JSON Schema uses "type": "integer". Wiz's MCP follows the Model Context Protocol spec correctly. It emits "integer" for numeric fields. n8n’s LangChain wrapper still doesn’t tolerate "integer", so when it introspects the tool schema it hits Cannot read properties of undefined (reading 'inputType') because the MCP node’s parser drops that field.

I was so excited when #21034 made it into a release, but it seems we're still blocked for the moment. :(

[aizerin]

I have the same problem with this mcp https://github.com/sooperset/mcp-atlassian

[matt-sullivan-alation]

same here, am using 1.120.4 .. made a primitive mcp to isolate:

this works:

@mcp.tool()
def ping(
sessionId: Optional[str] = None,
action: Optional[str] = None,
chatInput: Optional[str] = None,
toolCallId: Optional[str] = None,
) -> str:
return "pong"

this does not

@mcp.tool()
def add(
a: int,
b: int,
sessionId: Optional[str] = None,
action: Optional[str] = None,
chatInput: Optional[str] = None,
toolCallId: Optional[str] = None,
) -> int:
return a + b

[spheppner]

In am experiencing the exact same problem using a self hosted mcp server via the Django mcp server library.
One endpoint is working, its using only "number" input types for the parameters.

[david-at-appomni]

I spent WAY too much time on this. It's this, sort of: https://community.n8n.io/t/mcp-2025-06-18-specification/188337

This is what I think is happening:

Even though n8n is using a modern version of @modelcontextprotocol/sdk, conversion support for many of the MCP feature interactions with Zod seem to be broken. Bare with me, TypeScript is not my wheelhouse and I probably got some details wrong, but here's what I manic-stumbled through yesterday and last night.

MCP 2025-06-18 supports both integer and number: https://modelcontextprotocol.io/specification/2025-06-18/schema#numberschema, n8ns schema implementation doesn't.

After that it gets worse when we start throwing in anyOf input functionality, which is converted to a ZodUnion in parse-any-of.ts.

Since ZodUnion isn't represented in N8nTool.ts, it can't determine the input type for the union schemas and gives us the Cannot read properties of undefined (reading 'inputType') on the frontend, but if you force-click the execute button before the error message removes it, it'll send an empty dict, which is enough for some tools, like listing CRUD views with default params.

https://github.com/n8n-io/n8n/blob/master/packages/%40n8n/nodes-langchain/utils/N8nTool.ts#L11

For the Backend, no anyOf combination works properly because getSimplifiedType() doesn't handle ZodUnion, which breaks the tool description generation that the agent relies on to understand what fields to provide.

That means that even if you fix/work-around/ignore the frontend schema validation issues in the UI, the agent never knows what to the send the tool, and so it sends it all of the key-values from previous nodes (typically chatInput, sendMessage button, etc).

I need to move forward on this project, so I'm evaluating the following on my company's behalf:

1. Replacing the n8n agent with a third party option and calling it from within my workflow
2. Hacking an MCP proxy between n8n's MCP tool and the third party SaaS provider's MCP endpoint to try and shoehorn some sort of temporary fit
3. Using something besides n8n for developing, deploying, and operating Agents for our company

If I had the skillset to help remediate this, I would. At this point it's probably gonna have to be option #3.

Hope this helps more than it confuses.

[n8n-assistant]

Hi @clcc2019 👋

Thanks so much for your patience while we’ve been improving n8n. We know it’s taken some time to review this issue, and we’re currently updating our triage process to better keep up with our growth.

There have been a lot of improvements in recent releases, so we’d really appreciate it if you could check whether this issue still occurs in the latest release.

When you have a moment, please copy and paste the checklist below as a comment so our system can update the status automatically:

[ ] I have updated to the latest stable version of n8n [please specify version number] and I am still experiencing this issue
[ ] Please close this issue – I am no longer experiencing it
[ ] Please close this issue – [please specify a reason]

If we don’t hear from you in the next 14 days this issue will be automatically closed, feel free to reopen - don’t forget to add the checklist above so that our automated systems notify us of the issue.

Thanks again for helping us keep n8n healthy and up-to-date 💚

[david-at-appomni]

[x] I have updated to the latest stable version of n8n 1.123.1 and I am still experiencing this issue
[ ] Please close this issue – I am no longer experiencing it
[ ] Please close this issue – [please specify a reason]