Inconsistent behavior with $fromAI parameter types and MCP tool integration

[DirkSchlossmacher]

Bug Description

There are several issues when using the $fromAI expression within "Call n8n Workflow Tool" nodes under a "MCP Server Trigger" node:

1. Inconsistent JSON handling in $fromAI expression:

Assume a sub-workflow (WF #1) is defined to expect an input parameter named jsonObj of type object and the calling tool under "MCP Server Trigger" uses $fromAI to populate it:

• Using the UI button "Let the model define this parameter" and manually adding description a valid json object: this expression is generated:

  {{ $fromAI('jsonObj', `a valid json object`, 'string') }}

  This results in inconsistent behavior — sometimes the LLM generates a tool call with a valid JSON object, and sometimes a stringified JSON: this causes the called WF No json data from any APIs #1 to fail randomly.

• If expression is manually changed to:

  {{ $fromAI('jsonObj', `a valid json object`, '**object**') }}

  Then:

  • Sometimes results in: Error in sub-node ‘MCP Client‘: Could not connect to your MCP server
  • Or, the MCP tool is not used at all

• If changed to:

  {{ $fromAI('jsonObj', `a valid json object`, '**json**') }}

  Then again, the MCP tool is no longer used by the LLM.

Documentation issue:
Contrary to the $fromAI documentation, which states:

$fromAI("key", "description", "type", defaultValue?)
type: string | number | boolean | json

neither type json is supported, nor does object work.

Only stringworks BUT only if the prompting and parameter description is clearly hinting the LLM to profide a stringified json object as value.

---

2. Mandatory Parameters in MCP Tool:

When defining parameters in the sub-workflow and referencing it in the MCP tool, all parameters are treated as mandatory by default, with no way to mark them as optional in $fromAI.

According to the MCP standard, there should be ability to mark parameters of MCP tools as optional mandatory. See also: https://community.n8n.io/t/add-optional-parameter-support-to-fromai-in-ai-agent-tool-node/72877/5

---

3. Type Reversion Bug:

When $fromAI is manually edited and then the "Let the model define this parameter" button is clicked again, the type is reverted back to string, even if it was previously manually set to object or json in the expression editor.

To Reproduce

1. Create a sub-workflow (WF No json data from any APIs #1) with an input parameter jsonObj of type object.
2. In a workflow with "MCP Server Trigger" add "Call n8n Workflow Tool" to call WF No json data from any APIs #1. Then use the MCP tool in a 3rd WF (WF [doc] contributing guide #3) to call WF No json data from any APIs #1 via MCP Server.
3. Use $fromAI('jsonObj', 'a valid json object', 'string') or edit it to 'object' or 'json'.
4. Observe inconsistent behavior or errors.
5. Try to mark parameters as optional — not possible.
6. Reopen the $fromAI editor — type resets to 'string'.

Expected behavior

Expected Behavior:

• $fromAI should respect the specified type (object, json - what ever is right - currently none of bost works reliably) and consistently pass valid data.
• Parameters should be configurable as optional or required.
• UI should not reset the type when re-editing $fromAI.

Operating System

Azure Web App Container Reg

n8n Version

1.91.3

Node.js Version

unable to find on Azure

Database

PostgreSQL

Execution mode

main (default)

[Joffcom]

Hey @DirkSchlossmacher,

We have created an internal ticket to look into this which we will be tracking as "GHC-1966"

[DirkSchlossmacher]

MCP_client_n8n_issue.json
MCP_svr___n8n_issue (1).json
MCP_WF_n8n_issue (1).json

[Joffcom]

Hey @DirkSchlossmacher,

I am not fully sure what the issue is here, Are you able to try again without using AI to generate the report? I am not sure if this is a bug or an enhancement request it looks to be an enhancement request but it is very confusing.

[DirkSchlossmacher]

@Joffcom Thanks, idea to use AI was to make it more readable rather than less......
Now I revised it manually. Pls see again.

There is only one bit that you may consider as feature request (allowing to make MCP exposed params as optional)

The other points should be bugs

[n8n-assistant]

We’re taking some time to review and tidy up our issue tracker. It looks like this issue hasn’t had any recent activity for the past 6 months. To keep our backlog focused on current priorities, we’re closing this issue for now.

That said, this doesn’t mean the issue is forgotten! If this is still relevant or you have more information to add, feel free to reopen it or create a new issue and we’d be happy to revisit it.

Thank you for understanding and for contributing to the project!