I’m trying to use the documented path parameter mechanism in MCP Servers:
I have been able to establish a parameter based path using the following as my path:
“/:$MCP_ID”
This resolves when I connect to my MCP server from an AI Agent. I can select tools and I’m able to use the MCP server. But I am unable to retrieve my MCP_ID parameter value.
No error, just not able to use my parameter value from my MCP Server tool.
Follow up question… are the variables usable in MCP Server paths the environment variables that are only available from a Pro or Enterprise plan?
Is no one else trying to do this?
I also would like to find a way to do that.
Is there any way to send parameters from an AI agent to its MCP Client, to the MCP server and finally to the MCP tool?
From what I’m experiencing, MCP Server/Client do not support sending or receiving parameters.
You can (do that) by the way.
@cutecatcode would you be able to provide the steps to make this work? The n8n documentation on it is severely lacking in implementation information. Would really appreciate any info you can provide :).
Okay, I will give you a sample and steps to make the each MCP communicate.
If it helps you to understand, kindly mark my message as solution, thanks!
Hey @cutecatcode thanks for your input :). Unfortunately I’m already at this point. I’ve got lots of MCP servers stood up and I can use them. The problem is when I try to use the Path feature in the MCP Server trigger, it does not work. I can define a path parameter, and when I use my MCP server it only works if my path includes a parameter value. But the value is not available to me in my MCP Server workflow.
Have you tried to use the Path parameter feature? Thanks!
Can you give me a workflow-example?
Interesting — I ran into a similar issue when trying to read dynamic route params from the request in a tool call. Have you tried logging the full req.params or req.body inside the MCP Server handler to confirm where the value ends up? Sometimes it’s a small naming mismatch or formatting quirk. Let me know if you solve it!
Thanks @cutecatcode, sample code below.
It looks like the dynamic nature of MCP tool resolution does not come through in these code examples. Here’s a screen shot of the ‘MCP Client’ tool connected to the AI Agent.
Hi @Jackson how do I reference req.params? {{ $req }} does not resolve. Is it buried somewhere?
Thanks for showing us your workflow. I suspect you’re using old n8n version.
Take a look at this my workflow
Look at the MCP Server Trigger version, my version is V2 while your MCP Trigger node is V1
Nothing different with your nodes except I’m not adding memory there.
Try to update your n8n to latest version if you self-hosted it.
You can navigate to this documentation for updating n8n version
If it helps, kindly mark my message as solution, thanks:)
Thanks @cutecatcode, I am on 1.100.1 but was using an older version of the MCP trigger. I replaced it and I do see how the URL is differently built now. No change in ability to see the parameter value though. In the 2nd example you sent, I see you are sending a ‘url’ route parameter, but you are not using it in your Code Tool. How would you use it in that Code Tool?
Thanks!
the :url only for defining variable for mcp path variable like as what you do in /:MCPID, there’s nothing affected to related tool in MCP Server Trigger node (In my case is Code Tool).
You don’t need to add /sse path anymore in your MCP Client tool, if you already update your MCP Server Trigger node, it will give you only path without /sse route, so you can remove the /sse route from your MCP Client tool node. Hope it helps.
So, it’s purely to allow for each URL request to the MCP server to be unique? What is the point of that? This is a huge missed opportunity on n8n’s part if I cannot retrieve that parameter.
Do you know of a way to at least pull the URL used for the MCP server call? I can then extract the parameter value.
I don’t understand why I would want to make the MCP server URL dynamic via parameters if I have zero access to the parameter.
Sorry, I know you didn’t create this feature and you are just trying to help. I’m hoping someone from n8n is reading these threads and realizes how ridiculous it is that I can add dynamic parameters to my MCP Server URL but they are 100% unavailable and so serve zero purpose.
As far I know, why n8n do that is for the security. Every time you create a new MCP Server Triggers node, it will generate random UUID for the MCP path.
That’s why you don’t need to create dynamic parameters for MCP if you do not need that.
Thanks @cutecatcode 
That is unfortunate if this is just an attempt at security through obscurity. There is nothing secure about it. A randomly generated UUID makes sense to keep it unique, but running it over SSL and establishing one of the authentication mechanisms is the way it gets secured.
Now I am really curious if security was the intended purpose of these route parameters. The documentation does not state that as their purpose and dynamic URL segments is a means of RESTful parameter passing, not security AFAIK. Is there a way to request a response from N8N themselves on this subject?
These MCP Servers would be so much more powerful if I could blend contextual parameters with AI driven parameters.
@cutecatcode you have been amazing helping me. I do apologize for sounding upset. I am very annoyed with N8N’s lack of attention to this. Just a simple ‘not supported’ or ‘yes, this is a bug’ answer would be so helpful. Instead we are left guessing… But you’ve been awesome!
It is not a security option and I am not really sure how that even came up as a suggestion 
The UID is there to ensure unique urls but that isn’t the same as a path param.
Looking at it I don’t think we ever implemented it as an option for the MCP trigger which is why we don’t document that you can use it, I will pass your GitHub issue to the AI team though so they can have a look at it.
