Inbound
MCP clients connecting to you
Third-party MCP clients reach MCP servers and APIs protected by WebFrolic. You approve them from the CIMD catalog and control their scopes, as described on this page.
Explore ↗Solutions / AI agents
MCP Clients with CIMD
MCP clients such as AI assistants and coding tools act on a user’s behalf, so they need an identity you can trust. WebFrolic uses Client ID Metadata Documents (CIMD) in both directions. Third-party MCP clients connect to your MCP servers with an HTTPS URL as their client ID, but only clients an administrator picks from a catalog. MCP clients you build on WebFrolic reach other applications through Connections, with WebFrolic identifying itself by its own CIMD URL.
Available now in WebFrolic.
Two directions
Let MCP clients in, or build your own.
WebFrolic works on both sides of MCP authorization.
Outbound
MCP clients you build on WebFrolic
Your own MCP client uses Connections to reach users’ resources in other applications. WebFrolic stores each user’s tokens server-side and identifies itself with the CIMD document at /.well-known/client-metadata.json on each tenant domain.
Explore ↗Across apps
Cross App Access
Where the target application trusts your identity provider, an ID-JAG replaces a separate consent screen.
Explore ↗Why it matters
Open self-registration lets anyone call themselves a well-known client.
Without registration, every MCP client means a manual setup. With open Dynamic Client Registration, a fraudulent client can register under a trusted-looking name and ask users for consent. CIMD with an administrator-curated catalog avoids both problems.
Verified identity
Client ID is a URL
The client_id is the HTTPS URL of the client’s metadata document, so redirect URLs are anchored to the client’s own domain.
Curated, not open
A catalog of popular clients
Administrators enable clients from a catalog of popular CIMD-supporting MCP clients. Open Dynamic Client Registration stays off.
Least privilege
Defaults, then extras by choice
A scope attribute marks which scopes approved MCP clients get by default. Administrators manage any additional scope assignments.
The building blocks
What makes it work.
Catalog
MCP client catalog
Pick the MCP clients your organization allows. Only selected clients can start an authorization flow.
Explore ↗Authorization
MCP default scopes
As the identity provider, mark a scope as assignable to MCP clients by default. Scopes without the mark are never granted to them automatically.
Explore ↗Authorization
Additional scope assignments
Grant a specific MCP client more scopes when a use case needs them, and remove them just as easily.
Explore ↗Choose the clients
From the MCP client catalog, select the MCP clients your organization allows.
Mark default scopes
On each authorization scope, set whether it can be assigned to MCP clients by default.
Add scopes where needed
Manage additional scope assignments for any MCP client that needs more than the defaults.
Review the activity
Users consent as usual. Token requests and consents appear in the audit trail with the MCP client and the user.
Before rollout
Questions worth answering.
Settle these first and the rollout is mostly configuration.
- List the MCP clients your users already want to connect.
- Decide which scopes are safe for any approved MCP client, and mark only those as default.
- Keep write and administrative scopes out of the defaults, and grant them as additional assignments.
- Decide whether DPoP should be required for MCP client tokens.
- Agree on who can add a client to the allowed list and who reviews it.
Related capabilities
Explore what connects to this.
These capabilities are usually configured together.
Evaluate with your scenario
Start with a concrete workflow.
Share the identities, resource boundary and decision you want to test. The walkthrough can focus on the relevant behavior rather than a generic feature tour.