Enhancement: n8n-mcp workflow generator should use FQN references

[gander]

Problem Description

The generator emits $json.field instead of $('Node Name').item.json.field. The shorthand carries no node name, so reordering nodes silently breaks all references.

n8n users have requested FQN-by-default for years with no result. n8n-mcp generates JSON programmatically and always has the node name available -- this is the right place to fix it.

Expected Behavior

$('Node Name').item.json.field

Actual Behavior

$json.field

[czlonkowski]

Thanks for the thoughtful write-up, @gander — and you're right about the underlying failure mode. $json.field shorthand carries no source-node identity, so reordering or re-wiring nodes can silently change what $json resolves to, whereas $('Node Name').item.json.field is stable against topology changes. Generating FQN references by default when the node name is known is a reasonable default.

One important bit of transparency on where this would actually land. The n8n_generate_workflow tool in this OSS repo doesn't contain the generation logic itself. In src/mcp/server.ts the tool delegates to an injected generateWorkflowHandler:

case 'n8n_generate_workflow': {
  this.validateToolParams(name, args, ['description']);
  if (this.generateWorkflowHandler && this.instanceContext) {
    // ... handler produces the workflow JSON (and thus the expressions)
  }
  // self-hosted: no handler -> hosted_only message
  return { hosted_only: true, message: 'The n8n_generate_workflow tool is available exclusively on the hosted version of n8n-mcp. ...' };
}

In self-hosted builds that handler isn't present, so the tool returns the "available on the hosted service" message and produces no workflow at all. The expression-emission behavior you're describing — $json vs FQN — is decided inside that hosted backend, not in this repository. So this isn't something a change in this repo can implement; the fix belongs in the hosted generation service.

I've triaged this and I'm tracking it as a backlog item against the generator so the request isn't lost, but I can't commit to a timeline. I don't want to imply otherwise.

If it helps in the meantime: workflows authored or edited via the validation/diff tooling that does live here (e.g. validate_workflow) aren't rewriting your expressions, so if you hand-write FQN references they'll be preserved. And if you're up for it, a community PR that adds an FQN-preference lint/validation check on expressions in this repo would be welcome as a complementary guard, even though the generator default itself lives elsewhere. Leaving this open to track the generator-side request.