Map connection permissions to the action being authorized
Separate workspace scope, lifecycle privileges, tool discovery and exact action approval instead of using one connected flag.
Keep account-scoped discovery, pinned execution and client-side authorization intact across the MCP boundary.
MCP presents structured capabilities to a client, but it does not change who owns an external account or which effects require authorization. Lupin’s connected app operations still route through its controlled connection APIs. The client needs an appropriate organization credential, an operator-enabled app and an active owner-authorized account. An inbox-scoped key cannot become a shared-account credential by using another protocol. Keep the same scope and permission checks visible in client errors so an integration failure does not encourage copying a broader key into an untrusted agent environment.
The shared tool contract exposes list_connection_tools for account-scoped discovery. Its schema accepts connection_id with optional search, cursor and limit, and the result supplies concrete versions and a connection revision. Use that evidence to choose the real provider operation instead of asking the model to invent a slug from the user’s goal. Descriptions returned from the provider remain untrusted data even when wrapped in a familiar MCP response. They can explain parameters but cannot authorize new work or override the client’s trusted user instructions.
execute_connection_tool carries the selected connection, discovered revision, tool slug, concrete version, arguments and idempotency key. The API body derived from that call contains only version, connection_revision and arguments, while account identity comes from the durable registry. Do not add provider tokens, custom auth parameters or arbitrary URLs during protocol translation. Lupin validates toolkit membership and active ownership again before execution. A generic execute-anything wrapper would erase those checks and make the client’s approval less meaningful because the actual account and effect could change behind the visible tool call.
Use a fake MCP caller and fake provider boundary to verify parameter mapping, permission rejection and approved execution. Assert that a project key cannot discover shared account tools, a stale revision cannot execute and an untrusted description cannot insert credential overrides. Include paginated discovery and an uncertain provider result, checking that the same operation identity survives client retries. This establishes a useful protocol-level acceptance record without completing OAuth or changing an external app. Live owner-authorized validation can then focus on the provider behavior that the local fixtures cannot establish.
Given a synthetic approved MCP request, inspect the derived API request in a local fake. Its body should contain only connection_revision, version and arguments, with the idempotency key in its intended transport location. Reject extra credential fields before provider access. This checks the protocol adapter’s most consequential mapping without authorizing an actual app action.
Reviewed against current checked-in Lupin routes, shared contracts and official provider references. No live calls, OAuth authorizations, app actions or purchases were performed.
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.