workflow as mcp server #22212

Open
opened 2026-02-21 20:16:10 -05:00 by yindo · 2 comments
Owner

Originally created by @matteo-rama on GitHub (Feb 12, 2026).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Hi, i am using a workflow and then expose the WF as mcp server. i can map all the input param as expected and describe it.

What is missing imho is the ability to specify in mcp server (when is created?) some custom header field that agent must inject before calling our tool.

Some MCP require custom auth, imagine a token that is used to check if the mcp can be used or not, and the token is dynamic. Usefull for "sensitive" things and in b2b scenario, where a short lived token is used and is added "on top" of the agent that invoke the tool.

does it make sense?

2. Additional context or comments

No response

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @matteo-rama on GitHub (Feb 12, 2026). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] Please do not modify this template :) and fill in all the required fields. ### 1. Is this request related to a challenge you're experiencing? Tell me about your story. Hi, i am using a workflow and then expose the WF as mcp server. i can map all the input param as expected and describe it. What is missing imho is the ability to specify in mcp server (when is created?) some custom header field that agent must inject before calling our tool. Some MCP require custom auth, imagine a token that is used to check if the mcp can be used or not, and the token is dynamic. Usefull for "sensitive" things and in b2b scenario, where a short lived token is used and is added "on top" of the agent that invoke the tool. does it make sense? ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [ ] I am interested in contributing to this feature.
yindo added the 🌊 feat:workflow label 2026-02-21 20:16:10 -05:00
Author
Owner

@crazywoola commented on GitHub (Feb 12, 2026):

I’m not entirely sure what you mean. Are you trying to say:

  • When adding third-party MCPs to our MCP page, we should support using custom headers?
  • After publishing a Workflow as an MCP, it needs to support dynamic custom headers?
@crazywoola commented on GitHub (Feb 12, 2026): I’m not entirely sure what you mean. Are you trying to say: - When adding third-party MCPs to our MCP page, we should support using custom headers? - After publishing a Workflow as an MCP, it needs to support dynamic custom headers?
Author
Owner

@matteo-rama commented on GitHub (Feb 13, 2026):

hi @crazywoola , i was referring after publishing a workflow as MCP server, so case 2 of your scenario.

imho it will be beneficial to have the ability to get custom header on MCP server and having them passed as "variable" to the workflow for further usage (use them in an http task to check auth grants, or other scenario)

imho, they could be useful even in workflow exposed as trigger or api, just to say. Sometimes is not pratical to have in the WF input auth variable, and will add a good segregation of duty and scope.

if in input i can add something like "header" as a "type" (we have string, paragraph, single file...) and handle the new type in every aspect of the 'entry point' for the workflow (mcp, api, hooks) it will meet my idea.

people will add an "header" type on input, set X_FORDWARDED_FOR as header name and that's it you got your header.

@matteo-rama commented on GitHub (Feb 13, 2026): hi @crazywoola , i was referring after publishing a workflow as MCP server, so case 2 of your scenario. imho it will be beneficial to have the ability to get custom header on MCP server and having them passed as "variable" to the workflow for further usage (use them in an http task to check auth grants, or other scenario) imho, they could be useful even in workflow exposed as trigger or api, just to say. Sometimes is not pratical to have in the WF input auth variable, and will add a good segregation of duty and scope. if in input i can add something like "header" as a "type" (we have string, paragraph, single file...) and handle the new type in every aspect of the 'entry point' for the workflow (mcp, api, hooks) it will meet my idea. people will add an "header" type on input, set X_FORDWARDED_FOR as header name and that's it you got your header.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#22212