Problem
MCP Apps discovery is currently underspecified. Servers can expose app resources and tool metadata once connected, but users and hosts generally discover MCP Apps through manual setup, host-specific registries, or product-specific flows. This relates to broader MCP server/connectors discovery questions.
This is a significant hurdle for wide user adoption.
Related areas:
Context
Some hosts already have their own discovery mechanisms for their registries (not necessarily an MCP subregistry). However, it's uncommon, and currently fragmented by design. Whether or not this is an MCP Apps concern remains to be seen.
Questions for the workgroup
- What should be discoverable: MCP servers, app-providing servers, individual app resources, app capabilities, or all of these?
- Should Apps discovery be an extension of MCP Registry metadata, a server-declared manifest, host-specific registry metadata, or a combination?
- Do hosts need structured metadata before connecting to a server, or is post-connection discovery enough?
Desired outcome
Collect concrete discovery use cases and align with adjacent MCP working groups before deciding how to proceed.
Problem
MCP Apps discovery is currently underspecified. Servers can expose app resources and tool metadata once connected, but users and hosts generally discover MCP Apps through manual setup, host-specific registries, or product-specific flows. This relates to broader MCP server/connectors discovery questions.
This is a significant hurdle for wide user adoption.
Related areas:
Context
Some hosts already have their own discovery mechanisms for their registries (not necessarily an MCP subregistry). However, it's uncommon, and currently fragmented by design. Whether or not this is an MCP Apps concern remains to be seen.
Questions for the workgroup
Desired outcome
Collect concrete discovery use cases and align with adjacent MCP working groups before deciding how to proceed.