langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 03:55:25 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Updating MCP tool signatures breaks the node #15921

New Issue
Closed
opened 2026-02-21 19:23:58 -05:00 by yindo · 1 comment
yindo commented 2026-02-21 19:23:58 -05:00
Owner
Copy Link
Copy Source

Originally created by @DavideDelbianco on GitHub (Aug 5, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • 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.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.7.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I know, it is expected for the node to stop working if you change the MCP tool and refetch its definition.
But the issue is that after fetching the new definitions, the new parameters are appended to the existing tool node instances and the node retains old param label, and param declarations (in DSL)

Guidance

  • Publish as MCP workflow Tool A and give it a parameter 'named_parameter'
  • In Workflow B use MCP tool A and bind the workflow variable 'something' to the input param 'named_parameter'
  • Now update Tool A and rename the parameter from 'named_parameter' to 'named_parameter_new'
  • Refetch the Tool A MCP server
  • Open Workflow B and you will see the input empty (because it changed name, AS EXPECTED)
  • Bind again 'something' to the new param 'named_parameter_new'

Execute the tool for example using the "Run Step" action

✔️ Expected Behavior

The node should be update, with the new param definitions and their labels
Executing the node should report as input only the new parameters

❌ Actual Behavior

You will see in the node execution log inputs both 'named_parameter' and 'named_parameter_new'
Inspecting the DSL will reveal that both params are defined for the tool and the param label still uses the old value.
The old param might also change its variable binding to something else if for example the tool had another parameter bound to another variable

You have to either remove the node and add it back again, or to manually fix the DSL.

Originally created by @DavideDelbianco on GitHub (Aug 5, 2025). ### 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] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [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] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.7.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I know, it is expected for the node to stop working if you change the MCP tool and refetch its definition. But the issue is that after fetching the new definitions, the new parameters are appended to the existing tool node instances and the node retains old param label, and param declarations (in DSL) ## Guidance - Publish as MCP workflow Tool A and give it a parameter 'named_parameter' - In Workflow B use MCP tool A and bind the workflow variable 'something' to the input param 'named_parameter' - Now update Tool A and rename the parameter from 'named_parameter' to 'named_parameter_new' - Refetch the Tool A MCP server - Open Workflow B and you will see the input empty (because it changed name, AS EXPECTED) - Bind again 'something' to the new param 'named_parameter_new' Execute the tool for example using the "Run Step" action ### ✔️ Expected Behavior The node should be update, with the new param definitions and their labels Executing the node should report as input only the new parameters ### ❌ Actual Behavior You will see in the node execution log inputs both 'named_parameter' and 'named_parameter_new' Inspecting the DSL will reveal that both params are defined for the tool and the param label still uses the old value. The old param might also change its variable binding to something else if for example the tool had another parameter bound to another variable You have to either remove the node and add it back again, or to manually fix the DSL.
yindo added the 🐞 bug label 2026-02-21 19:23:58 -05:00
yindo closed this issue 2026-02-21 19:23:58 -05:00
yindo commented 2026-02-21 19:23:59 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 5, 2025):

This is a known limitation in Dify v1.7.1: when you update an MCP tool's signature (such as renaming a parameter) and refetch its definition, the workflow node keeps the old parameter(s) in its DSL and UI, and simply appends the new ones. The backend logic generates parameters for execution by matching the node's stored parameters with the current tool definition, but it does not remove obsolete parameters—these remain in the DSL and show up as None in execution logs. This is why you see both the old and new parameters in the node execution log and DSL after a signature change. There is no automated cleanup or migration for this as of v1.7.1, so the only workarounds are to manually edit the DSL or remove and re-add the affected node after a tool signature change. This behavior is confirmed in related issues and code analysis, and is not currently addressed by any official documentation or automated process (see discussion) (see code).

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 5, 2025): <!-- Answer --> This is a known limitation in Dify v1.7.1: when you update an MCP tool's signature (such as renaming a parameter) and refetch its definition, the workflow node keeps the old parameter(s) in its DSL and UI, and simply appends the new ones. The backend logic generates parameters for execution by matching the node's stored parameters with the current tool definition, but it does not remove obsolete parameters—these remain in the DSL and show up as `None` in execution logs. This is why you see both the old and new parameters in the node execution log and DSL after a signature change. There is no automated cleanup or migration for this as of v1.7.1, so the only workarounds are to manually edit the DSL or remove and re-add the affected node after a tool signature change. This behavior is confirmed in related issues and code analysis, and is not currently addressed by any official documentation or automated process [(see discussion)](https://github.com/langgenius/dify/issues/20247) [(see code)](https://github.com/langgenius/dify/blob/2575eaf1d6891d69133974fb8c7a2c7931385244/api/core/workflow/nodes/tool/tool_node.py). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/64f0a5a9-c62a-4ff6-b5c0-f0d6c2504c45?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/64f0a5a9-c62a-4ff6-b5c0-f0d6c2504c45?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/64f0a5a9-c62a-4ff6-b5c0-f0d6c2504c45?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/64f0a5a9-c62a-4ff6-b5c0-f0d6c2504c45?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/64f0a5a9-c62a-4ff6-b5c0-f0d6c2504c45?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/64f0a5a9-c62a-4ff6-b5c0-f0d6c2504c45?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/64f0a5a9-c62a-4ff6-b5c0-f0d6c2504c45?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23464)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15921
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?