Let $fromAI inherit descriptions and option values

Questions
1

Describe the problem/error/question

Hi! When selecting “Defined automatically by the model”, $fromAI gets an empty description instead of inheriting the node parameter’s existing description.

Also, static options and resourceLocator/listSearch results aren’t exposed to the model as enums—the model only sees a free-form string.

Could n8n use parameter.description as the default and map available options to enum/oneOf in the runtime tool schema? This would avoid duplicated descriptions and make tool calls much more reliable.

I encountered this during custom node development and desperately trying to let the runtime agent know about the inputs. The options issue can be worked around by letting the ai choose a string and validate during runtime, but that lets the agent guess around trying to find a valid value when it could know the options in the first place.

I am very happy to provide a PR if that would help get either of these issues resolved :slight_smile:

Evidence

  • The auto-generated description defaults to an empty string and does not read parameter.description: fromAIOverride.utils.ts#L74-L80, #L157-L179.
  • options fields are excluded from new AI overrides, while other unsupported field types—including resource locators—become plain strings: #L72, #L106-L114.
  • Runtime schema generation creates scalar schemas only; it never creates an enum from options or listSearch results: from-ai-parse-utils.ts#L27-L100.

Information on your n8n setup

  • n8n version: 2.31.5
  • Database (default: SQLite): Postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker
  • Operating system:
3

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

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@jnscb, @solomon - 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.

4

@JUVOJustin , this sounds like a feature request.

I believe this can avoided by declaring tooling schema in the first place.
Does the model used conform to the Open AI standard?

5

Hello Justin,
One thing that might be worth ruling out before this gets triaged as a pure feature request: has anyone checked whether the auto-generated description ever populated from parameter.description in an earlier release? A few $fromAI fixes landed recently — #31681 in 2.28.0 (“Keep $fromAI placeholders intact on fields with expressions disabled”) and #31495 for expression evaluation in AI tool descriptions — so that area has been moving.

You’re on 2.31.5, so you already have both. If you have a throwaway instance, spinning up 2.28.0 and checking whether the override description behaves differently there would settle it either way: if it’s identical, this is confirmed as a gap that was always there and your PR offer is the right path; if it differs, it’s a regression and gets prioritised very differently.

6

Hi @JUVOJustin
Both of those are workable today, even though the duplication is the thing you want removed. Click the X on the auto-filled parameter to revert it, and the expression field keeps the generated $fromAI() call so you can edit it by hand. Write the second argument yourself and list the valid values inside it, so the model sees the allowed set instead of guessing at it:

{{ $fromAI('operation', 'Which operation to run. One of: create, update, delete', 'string') }}

For the change itself, node and schema work gets picked up on GitHub rather than here, so open an issue on the n8n repo with the source lines you already pinned down and offer the PR there.

7

Thanks all for your replies :). I posted it here since i feel my issues sits somewhere between feature requests and bug report. I feel this functionality should be be there ootb but i guess one might have a different perspective on that :smiley:

Sadly this is not reasonable if you have a long and potentially even dynamic list of options. Especially since i am talking about this working by default for nodes to improve general guidance for llms.

I am not entirely sure what you mean. Model used was mistral, but the code i referenced in my post likely has the same issue no matter which model you use.

I posted this here mostly to get a feeling if this is to be considered a bug or a feature request. In my opinion it is more on the bug side in which case i would happily create the github issue. If my findings are correct this means all nodes used as tools for runtime agents have no parameter usage instructions except manually specified. My feeling is this could improve tool calling efficiency alot.

8

The label won’t decide anything for you. n8n’s repo has blank issues disabled and Bug Report is the only template, and the feature request option on that page links straight back to this forum, so the bug form is the one route that actually reaches the repo. File it there with the reproduction and expected behaviour sections filled in, and let triage relabel it if they read it as an enhancement.
There is precedent for this exact class. #28261 was a $fromAI override gap hit during community node development, filed as a bug, assigned to the AI team, and closed by a PR.

For the PR itself, a bug fix needs the linked issue plus a regression test that fails against current master, and an enhancement needs a forum topic first, which this thread already covers.

On which channel takes what: