Explore MCP App discovery mechanisms #670

Activity

1. idosal

   added

   enhancementNew feature or requestNew feature or request

   protocol

   on May 26, 2026
2. Chipagosfinest commented on Aug 17, 2026

   

   Chipagosfinest

   on Aug 17, 2026

   More actions

   Bringing a comparison from Farcaster Mini Apps (formerly Frames), Neynar's host layer, and Telegram Mini Apps: I think discovery needs to be treated as several separate layers, rather than choosing one object as “the app.”

   1. App descriptor — developer-supplied, non-authoritative metadata: name, previews, logical entrypoints, and required/optional capabilities.
   2. Association/binding — claims connecting a logical app to the authenticated MCP server(s) and runtime UI resources that implement it.
   3. Discovery source — registry, direct descriptor URL, server resource, domain publication, deep link, or host-curated/private catalog.
   4. Registry assertions — catalog-operator claims such as review, verification, ranking, or policy eligibility.

   The identities should remain distinct too: authenticated MCP server principal, logical app, publisher claim, runtime resource/version, and registry listing. A server may expose multiple apps; an app may have multiple entrypoints or servers; resources can update without creating a new app; and a registry can delist an app without changing its identity. A descriptor is a claim, not proof of publisher identity, safety, review, or permission.

   The strongest reusable lesson from Farcaster's capability work is two-phase compatibility:

   • discovery metadata declares required capabilities so a host can filter, warn, or select a compatible entrypoint before launch;
   • optional capabilities allow graceful degradation;
   • runtime capability negotiation remains authoritative because support can vary by host, version, policy, user decision, and current context;
   • declarations never grant permission.

   Farcaster ended up with manifest-level requiredCapabilities / requiredChains plus runtime checks. The discussion includes concrete auth, share, and notification failures caused by uneven client implementations. MCP already has the runtime half in ui/initialize; a discovery profile could add the pre-connect half, ideally per entrypoint rather than only per app.

   I would make the first deliverable an optional, versioned App Descriptor and Discovery profile, but pause before writing the JSON schema until these questions converge:

   • What keeps an app identifier stable across resource, endpoint, publisher, and server updates?
   • How does a connected MCP server confirm a descriptor's association claim?
   • How do local/stdio apps participate without privileging a web domain?
   • Can one server publish multiple apps and one app bind multiple servers?
   • How are redirects, identifier migration, descriptor versioning, and revocation handled?
   • What must a host do when discovery-time requirements and runtime availability disagree?

   Once those are answered, a minimal descriptor could cover display metadata/previews, publisher/support/privacy claims, logical entrypoints and connection information, required/optional capabilities per entrypoint, launch/display constraints, and endpoint/resource association claims. The MCP Registry can bind to it, but registry-specific trust and ranking assertions should stay separate.

   I would keep these out of the initial discovery proposal while ensuring the identity model does not block them:

   • typed launch context and deep links;
   • scoped local/roaming/secure storage (#417);
   • host-mediated, short-lived identity assertions;
   • native share intents;
   • install/remove and re-engagement notifications;
   • host-mediated payment intents.

   Farcaster's manifest, embeds, add/remove lifecycle, and per-user/app/client notification tokens, Neynar's catalog/search and host responsibilities, and Telegram's many launch surfaces, signed launch data, native intents, permissions, and storage classes show why those capabilities matter. They should be independent profiles, not one omnibus extension, and sensitive operations should remain host-mediated, scoped, consented, auditable, and revocable.

   This would let ordinary tool-linked MCP UIs stay lightweight while giving durable/distributable apps a portable path toward a real Mini App ecosystem.