Proposal: Support for UX Elements and Tool chaining in MCP #563
Replies: 3 comments
-
|
There are some further points, that I would like to gauge feedback from the community here:
|
Beta Was this translation helpful? Give feedback.
-
|
You may be interested in this discussion and how its conclusion is basically that this is already possible with the current specification; no changes are needed. Separate from UI, here's a good jumping off point for thinking through multi-turn interactions. |
Beta Was this translation helpful? Give feedback.
-
|
Nice! Thanks for sharing, I like how the mcp-ui piece is evolving and find ways to converge this story. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Your Idea
The idea here is to improve the 2025-05 draft MCP specification for
Toolin a two-fold manner:With the increasing adoption of MCP servers, and the evolving tool usage to solve complex scenarios for agentic communication, it will become more common for consumers such as IDEs that implement MCP Clients to require the ability for interactive tool invocations and ability for users to dynamically provide inputs in a form-friendly manner. As the tool schema is preconfigured into the specification, the author of the tool can further prescribe how to render large form elements for optimal UX. This is an opportunity to accelerate the development of user interfaces through agents.
Secondly, as the number of available tools within a registry is expected to grow exponentially within the MCP Server, so does the complexity of the intelligent orchestration for the LLM/Agent to select the right tools for the job. In many practical cases, this might just be a deterministic sequence of tools (APIs) that the agent might have to invoke - we can therefore enhance the performance of this experience by making this set of
dependenciesexplicit to the LLM.Let’s take the example of a user who interacts with an Atlassian MCP Server to discover the list of tools. Assume this list now includes thousands of the available Jira APIs.
uischema in the specification, that can definitively aid the LLM and the MCP Client to render them as a dynamic form element to the user.Proposed Solution
Here is a modified version of the 2025-05 draft MCP specification, that translates the above idea into a usable definition. In this, we propose the addition of 2 new entities into the
Toolschema:ui: optional. Prescribes common JSON form elements for particular fields and provide hints to any renderer component to build interactive forms, dropdowns, buttons, and layouts. This must not be tightly bound to HTML/CSS as MCP clients can operate within the boundaries of any web/embedded/mobile toolkit framework.dependencies: optional. Prescribes the deterministic sequence of tool bindings to execute for this tool to be successful. It can pin specific output fields from API calls, or remain at the tool level.Concrete Example:
Here is an LLM generated Tools definition for the perplexity-ask MCP server, where I instructed it to create a dependency chain between the
perplexity_askandperplexity_researchtools to demonstrate the proof-of-concept:Scope
Beta Was this translation helpful? Give feedback.
All reactions