Input validation error,The parameter type of the tool added to the agent is inconsistent with the parameter type defined in MCPServer #15411

Closed
opened 2026-02-21 19:21:36 -05:00 by yindo · 3 comments
Owner

Originally created by @s0214lx on GitHub (Jul 15, 2025).

Self Checks

  • 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 (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.6.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

After adding the mcp tool to the agent, I checked the parameter type of the tool and found that it was inconsistent with the data type set in the MCP Server. When I executed the tool, I could see that the parameters were correct, but the execution failed ""Input validation error: '0.5' is not valid under any of the given schemas""

Image Image

✔️ Expected Behavior

No response

Actual Behavior

No response

Originally created by @s0214lx on GitHub (Jul 15, 2025). ### Self Checks - [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 (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.6.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce After adding the mcp tool to the agent, I checked the parameter type of the tool and found that it was inconsistent with the data type set in the MCP Server. When I executed the tool, I could see that the parameters were correct, but the execution failed ""Input validation error: '0.5' is not valid under any of the given schemas"" <img width="410" height="356" alt="Image" src="https://github.com/user-attachments/assets/5f1f80e3-c114-47b9-9e05-aff9908a4cc8" /> <img width="1682" height="666" alt="Image" src="https://github.com/user-attachments/assets/5e886f32-6839-4147-824f-17c211e4569e" /> ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior _No response_
yindo closed this issue 2026-02-21 19:21:36 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Jul 15, 2025):

Hi @s0214lx! I'm Dosu and I’m helping the dify team.

The input validation error happens because Dify flattens both 'integer' and 'float' types from the MCP tool schema into a generic 'number' type when mapping parameters. This means Dify does not distinguish between integers and floats—so if the MCPServer expects a strict type (for example, only integers or only floats), Dify might send a value that doesn't match, causing errors like "'0.5' is not valid under any of the given schemas" if, for example, an integer is expected but a float is sent. This is a limitation in Dify's current MCP tool integration and type handling logic, and there is no built-in way to preserve the distinction between integer and float types end-to-end in the current version (source).

To work around this, make sure the parameter types in your MCPServer schema and the values you send from Dify are strictly aligned. If the MCPServer expects an integer, ensure you send an integer (e.g., 1 instead of 1.0 or '1'). You may need to manually enforce or validate types in your tool definitions or adjust the MCPServer schema to be more permissive if possible.

There is currently no official documentation or built-in option in Dify to handle this distinction automatically, so careful schema alignment and manual validation are required.

To reply, just mention @dosu.


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

@dosubot[bot] commented on GitHub (Jul 15, 2025): <!-- Greeting --> Hi @s0214lx! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> The input validation error happens because Dify flattens both 'integer' and 'float' types from the MCP tool schema into a generic 'number' type when mapping parameters. This means Dify does not distinguish between integers and floats—so if the MCPServer expects a strict type (for example, only integers or only floats), Dify might send a value that doesn't match, causing errors like "'0.5' is not valid under any of the given schemas" if, for example, an integer is expected but a float is sent. This is a limitation in Dify's current MCP tool integration and type handling logic, and there is no built-in way to preserve the distinction between integer and float types end-to-end in the current version ([source](https://github.com/langgenius/dify/blob/bf542233a93d2d637b58cb5c5d4c1ce39d6bd053/api/services/tools/tools_transform_service.py)). To work around this, make sure the parameter types in your MCPServer schema and the values you send from Dify are strictly aligned. If the MCPServer expects an integer, ensure you send an integer (e.g., `1` instead of `1.0` or `'1'`). You may need to manually enforce or validate types in your tool definitions or adjust the MCPServer schema to be more permissive if possible. There is currently no official documentation or built-in option in Dify to handle this distinction automatically, so careful schema alignment and manual validation are required. <!-- 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/9297869e-a5ea-4a67-a9f9-7777fc0f9bdc?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/9297869e-a5ea-4a67-a9f9-7777fc0f9bdc?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/9297869e-a5ea-4a67-a9f9-7777fc0f9bdc?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/9297869e-a5ea-4a67-a9f9-7777fc0f9bdc?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/9297869e-a5ea-4a67-a9f9-7777fc0f9bdc?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/9297869e-a5ea-4a67-a9f9-7777fc0f9bdc?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/9297869e-a5ea-4a67-a9f9-7777fc0f9bdc?feedback_type=other)</sup>&nbsp;&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/22466)
Author
Owner

@s0214lx commented on GitHub (Jul 16, 2025):

@dosu,The parameter expected by MCPServer is of type float. I provided a decimal, but the problem still exists. The type defined in MCPServer is float, which should be mapped to numeric type in dify. However, I see it as string type in dify.

@s0214lx commented on GitHub (Jul 16, 2025): @dosu,The parameter expected by MCPServer is of type float. I provided a decimal, but the problem still exists. The type defined in MCPServer is float, which should be mapped to numeric type in dify. However, I see it as string type in dify.
Author
Owner

@dosubot[bot] commented on GitHub (Jul 16, 2025):

This happens because Dify's internal logic maps both 'float' and 'integer' types from the MCPServer schema to a generic 'number' type, but in some cases (such as in the UI or API), this can end up being treated as a string instead of a true numeric type. This mapping is handled in the convert_mcp_schema_to_parameter function, which uses a type mapping that flattens both 'float' and 'integer' to 'number', and then creates ToolParameter instances with this mapped type. If the value is passed as a string (e.g., "0.5" instead of 0.5), MCPServer's strict validation will reject it if it expects a float, resulting in the error you see.

Currently, Dify does not preserve the distinction between float and integer types end-to-end, and there is no built-in way to force the parameter to be sent as a true float. As a workaround, you could try adjusting your MCPServer schema to accept both string and number types for that parameter, or preprocess the value in Dify to ensure it's sent as a float, but this would require a code change in Dify's parameter handling logic. The relevant code for this mapping is here: convert_mcp_schema_to_parameter.

If you need to patch this, you would need to modify how Dify casts and sends parameter values for MCP tools, ensuring that float parameters are always sent as numbers, not strings. Let me know if you want a more detailed code walkthrough for this!

To reply, just mention @dosu.


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

@dosubot[bot] commented on GitHub (Jul 16, 2025): <!-- Answer --> This happens because Dify's internal logic maps both 'float' and 'integer' types from the MCPServer schema to a generic 'number' type, but in some cases (such as in the UI or API), this can end up being treated as a string instead of a true numeric type. This mapping is handled in the convert_mcp_schema_to_parameter function, which uses a type mapping that flattens both 'float' and 'integer' to 'number', and then creates ToolParameter instances with this mapped type. If the value is passed as a string (e.g., "0.5" instead of 0.5), MCPServer's strict validation will reject it if it expects a float, resulting in the error you see. Currently, Dify does not preserve the distinction between float and integer types end-to-end, and there is no built-in way to force the parameter to be sent as a true float. As a workaround, you could try adjusting your MCPServer schema to accept both string and number types for that parameter, or preprocess the value in Dify to ensure it's sent as a float, but this would require a code change in Dify's parameter handling logic. The relevant code for this mapping is here: [convert_mcp_schema_to_parameter](https://github.com/langgenius/dify/blob/aef67ed7ece1e6540201c689c1a24e702cf4d991/api/services/tools/tools_transform_service.py). If you need to patch this, you would need to modify how Dify casts and sends parameter values for MCP tools, ensuring that float parameters are always sent as numbers, not strings. Let me know if you want a more detailed code walkthrough for this! <!-- 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/14d599da-41c9-45bf-8a98-d0e4c2741206?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/14d599da-41c9-45bf-8a98-d0e4c2741206?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/14d599da-41c9-45bf-8a98-d0e4c2741206?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/14d599da-41c9-45bf-8a98-d0e4c2741206?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/14d599da-41c9-45bf-8a98-d0e4c2741206?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/14d599da-41c9-45bf-8a98-d0e4c2741206?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/14d599da-41c9-45bf-8a98-d0e4c2741206?feedback_type=other)</sup>&nbsp;&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/22466)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15411