Spaces:
Running
Behaviour of mcp_tools=True
Hi all, my Gradio app accepts strings as inputs, but these need to be processed further into numeric lists. However, my concern is that if the MCP functions were used as part of a larger pipeline, there would be a conversion overhead going from Numeric List-> string-> Numeric List. If I write a wrapper that converts string->List for example and use the wrapper in the gradio interface, will an LLM have direct access only to the string-based wrapper or also the underlying list-based function?
My expectation is that the LLM will see whatever function surface Gradio exposes through MCP, so I would make the MCP-facing wrapper the stable contract and keep the numeric-list implementation behind it.
For a production-ish agent pipeline, I would optimize for:
- explicit schema at the MCP boundary
- predictable validation/error messages
- one canonical representation in the logs/traces
- keeping the internal helper free to change later
The conversion overhead is usually less painful than exposing two subtly different tool shapes to the agent. The latter can make debugging much harder once the tool is used inside longer runs.