Route agent tools through registered REST handlers

One catalog selects bounded operations

Lupin’s shared channel catalog defines named operations, strict schemas, sensitivity metadata and a request mapping. The model selects a tool and arguments; it does not choose an arbitrary HTTP method or provider URL. This limits the adapter’s job to validating a known operation and dispatching it to the registered API path. A closed catalog also makes review practical because an operator can inspect which methods are exposed and which dedicated ceremonies remain outside the agent. Tool discovery is therefore a contract boundary, not a general network proxy.

Preserve the original caller credential

The MCP handler forwards the caller’s bearer authorization to the corresponding registered REST handler. That handler remains responsible for permissions, resource ownership, durable state, provider readiness and spending controls. The adapter does not use a privileged service key to make a denied request succeed. This matters for project and inbox keys: the same resource boundary must hold whether a worker calls REST directly or reaches it through a tool. API-key scope should not disappear when a request changes from an HTTP client to a conversational interface.

Handle scope-specific routing explicitly

Some tools need adapter checks in addition to normal REST enforcement. MCP rejects workspace-only tools for project or inbox keys, prevents inbox keys from creating inboxes and directs permitted project inbox creation to the calling key’s project route. Usage queries select the metric endpoint appropriate to the key’s scope. Keep such mappings explicit and tested rather than asking the model to supply a correct project path. A resource identifier received in an email still cannot override the authenticated organization or cause the adapter to select another tenant’s credential.

Leave ceremonies in their dedicated flows

Authentication, new API-key issuance, human team management, organization transfers, global administration and provider webhook receivers are not arbitrary agent tools. Some require verified human sessions, dedicated signatures or other authority the tool catalog does not provide. Autonomous registration remains a public HTTPS ceremony performed before bearer-authenticated MCP. Human claim stays in the private console. This separation prevents a model from composing a sequence of ordinary-looking tools that silently mints broader access or treats a provider callback as a human-approved administration request.

Keep external-account execution pinned

Connected-app tools first use live discovery, then execute with the exact account revision, concrete tool version and validated arguments. Provider credentials, user identity and request URLs are server-derived rather than accepted from model input. An account reconnect invalidates a stale proposal instead of silently sending it through a different account. The resulting REST response becomes the MCP tool content, including real operational errors. Do not add an adapter fallback that returns simulated success when the provider is disabled or a business check rejects the request.

Test parity at the dispatch boundary

Use a local fixture to call one operation through REST and MCP with the same scoped key, then compare policy outcomes and returned resource state. Include ownership denial, provider unavailable and replay recovery. Your next step is a dispatch coverage check for every exposed catalog entry, so adding a conversational tool cannot bypass the existing business handler by accident.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin MCP registered REST dispatch ↗Checked 2026-11-05
• Lupin authentication ↗Checked 2026-11-05
• Lupin connected app execution ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.