How to pass variables from chat requests to MCP servers—via headers, body parameters, or other methods?

[zinodynn]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

In particular, different roles in MCP follow different rules; this distinction is achieved by passing identity variables to the MCP servers.

[zinodynn]

I’ve been using the input to pass variables for requests, and then modifying the FunctionCallAgentRunner to include these variables in tool_parameters. Is this a viable approach?

[dosubot[bot]]

Yes, passing variables via the inputs field in your request is the recommended way to make custom data available to your app's workflow—this is how Dify expects you to provide context or identity variables for downstream use, including MCP servers. Arbitrary fields outside inputs are ignored by the API, so using inputs is both viable and best practice for variable propagation in Dify workflows (source).

As for modifying FunctionCallAgentRunner to inject these variables into tool_parameters: while the codebase shows that tool parameters are dynamically generated from the variable pool and node data, and this approach can work, it's not the primary extension point Dify is designed for. Modifying core runners like FunctionCallAgentRunner can introduce risks—such as bypassing input validation or affecting logging and traceability—because Dify expects parameters to flow through well-defined mapping hooks or workflow nodes (source).

If possible, prefer using workflow variable assignment, agent skill plugins, or other extension points to map your inputs to tool_parameters, rather than patching the core runner. This will keep your integration more robust and maintainable.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[zinodynn]

Based on the above, could you please provide some specific suggestions? What classes can I change to achieve a better result?

@dosu

[dosubot[bot]]

For robust and maintainable variable passing from chat requests to MCP servers, focus on customizing the workflow nodes—especially the ToolNode class in api/core/workflow/nodes/tool/tool_node.py. The key method here is _generate_parameters, which maps variables from the variable pool (populated by your inputs) to the tool_parameters sent to downstream tools or MCP servers. You can subclass ToolNode or override _generate_parameters to implement advanced mapping logic, such as injecting identity variables or custom context as needed. This approach keeps your integration clean and leverages Dify's intended extension points, rather than patching core runners like FunctionCallAgentRunner, which can introduce maintenance risks. For more complex preprocessing, consider using variable assignment nodes or agent skill plugins in your workflow design.
See the relevant implementation details here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[zinodynn]

Is the PR’s proposal to send input parameters from chat requests to the tool servers a good idea? After all, we’ve always sent identity info to the MCP server to distinguish different roles. @dosu

[dosubot[bot]]

Yes, the PR’s approach to forwarding input parameters from chat requests to tool servers is a good idea and aligns with Dify’s architecture. This method is already supported and structured in the codebase—input variables are validated, mapped, and only those explicitly referenced in the workflow are forwarded to tool servers, not arbitrary payload fields. This design supports robust role distinction (such as passing identity info to MCP servers) and keeps integrations maintainable and secure by preventing accidental data leakage or unsanitized parameter propagation. For advanced needs, you can further customize parameter mapping at the workflow node level, especially via the ToolNode class and its _generate_parameters method, without modifying core runners like FunctionCallAgentRunner. This keeps your workflow clean and future-proof as Dify evolves.
See implementation details

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}