You choose the apps. The client clicks Connect.
With Allow reseller to manage Apps and MCP granted, you can browse the catalog, plan every app a client’s agents need, and get a connection ready to go. The moment a step needs the client’s login or their secret, the control locks. Not because of a missing scope, because it always does. This page shows you exactly where that line sits and how to hand it off cleanly.
Every connect control is locked in a delegated session.
There is no scope that changes this. It doesn’t matter what the client’s toggles say.
The same lock, the same lock icon, and the same tooltip appear on Connect, Reconnect, Grant access (the OAuth scope upgrade), Recheck, Disconnect, and Switch to OAuth. It disables the entire API-key form, input fields included, not just its submit button. It disables the app detail page’s Install button, Uninstall, and the confirm button on the Install plan sheet. If a control finishes a connection or touches a credential, it is locked.
What “Allow reseller to manage Apps and MCP” actually gives you.
The client grants this under the label Allow reseller to manage Apps and MCP. Its full description, in the product’s own words: “Manage the Apps section, including tools, MCP servers, and app connections that don’t require credentials. Installing credential-based apps, connecting OAuth apps, and disabling or modifying anything tied to API keys, OAuth tokens, or other secrets is always off-limits, regardless of this setting.”
Marketplace browsing itself is deliberately never locked, delegated or not. You can always look, compare, and plan. What changes is whether you can act on what you find.
The Apps section, scope by sub-page.
The Apps nav item itself unlocks with tools_and_integrations OR skills, either one is enough to see it. Once inside, its three sub-pages each check their own scope.
If a delegated session carries only skills and not tools_and_integrations, it lands on the Skills sub-page rather than Browse. That’s deliberate: Browse needs tools_and_integrations, so a skills-only session would find it locked. The app routes you to the one page you can actually use instead of opening on a dead end.
Reading the catalog before you commit.
Every app declares its own connection method, OAuth, an API-key form, or both, so what a connection needs from the client varies app to app. Two sets of signals tell you what’s realistic before you request anything: the state chip on an Install plan row, and the badges on an app’s detail page. Reading both first means you can batch every request the client needs to act on into one message, instead of dripping requests in one at a time.
Read these before you write to the client, not after. A five-minute pass through the apps a client’s agents need turns into one clear message instead of three follow-ups.
MCP servers.
Be precise about what’s actually documented here, because MCP servers work a little differently from apps.
The MCP servers sub-page is gated at the route level by tools_and_integrations, the same scope as Browse. What the permission copy itself says is that the scope covers “MCP servers” alongside tools and app connections, as part of the same Allow reseller to manage Apps and MCP grant.
Beyond that route-level gate, the MCP servers page doesn’t carry the same per-action locks the Apps surface does. What that means for any specific action inside a delegated session isn’t part of the documented material available here, so this page won’t tell you that a reseller can, or can’t, complete a particular MCP install on the client’s behalf. Treat it as unresolved rather than assuming either way.
One thing is confirmed either way: an MCP server that requires its own OAuth authorization follows the same client-only rule as apps do. After it’s installed, that server shows a “Needs auth” state until the client completes the consent screen in their own account, at which point it turns connected. If a step needs the client’s login, it needs the client, MCP server or app, no exceptions.
For the full reference on what MCP servers are and how they’re configured, see MCP servers.
Requesting a connection well.
The client’s side of a connection is short: they sign in to their own account, open the app, click Connect, complete the provider’s consent screen in their own browser, and the connection appears. Your job is making sure they know exactly which apps, in one pass.
Identify every app the client's agents need
Batch the requests into one message
Name the exact app and the exact button
Let them authorize on their side
Verify from your side
A short template covers most handoffs. Adjust the app list to what’s actually missing for that client.
Troubleshooting connections.
A quick index for the signals you’ll actually see while reading a client’s Apps section from inside a delegated session.
For issues that go beyond the Apps section, see the full Troubleshooting index.
Plan it fully. Hand off cleanly.
Everything short of the client’s own login and secrets is yours to configure.
Every connect, install, and credential control locks for any active delegated session, no scope changes that.
Marketplace browsing stays open the whole time · so does everything short of the client’s login.