Check provider readiness separately from permissions and quotas

Availability has several independent layers

A tool can exist in the shared catalog while its provider is unconfigured, the workspace lacks an allowance or the calling key lacks permission. Documentation describes an implemented operation, not a guarantee that every deployment and account can run it. Separate provider readiness, workspace enrollment, plan allowance, key scope, permissions, verification and spending admission in your client model. This prevents an agent from promising a browser, call or app action based only on seeing a tool name in discovery.

Start with the capability response

GET /v0/capabilities reports configured product capabilities and the available app catalog view. Read it with the actual workspace key and use the returned status rather than a hardcoded marketing list. A missing or disabled provider should remain unavailable; Lupin returns real configuration errors rather than simulated success. Capability discovery is descriptive and does not purchase anything, enroll a plan or grant a wider credential. Keep the result fresh enough for the task, especially after an operator changes provider setup.

Check the workspace’s actual allowance

Configured browser infrastructure is separate from a workspace allocation. Existing unenrolled workspaces do not automatically acquire browser or sandbox allowance merely because tools were deployed. Any explicit Free enrollment belongs in the intended owner-approved billing flow; do not enroll silently as a convenience step. Newly autonomous workspaces have a bounded Free policy with overages off and spending zero, while their bootstrap key lacks paid-resource authority. The existence of a plan allowance still does not override that credential’s permission boundary.

Discover apps through the catalog

Use GET /v0/connections/catalog with search and pagination to inspect operator-configured apps. include_unavailable can reveal setup-required or no-auth entries without implying they can start account authorization. Capabilities contains only a bounded first set of apps plus pagination metadata, so it is not the complete searchable catalog for a large deployment. A supported app blueprint is also different from an active connected account and a discovered executable tool. Verify each stage rather than claiming that the agent can operate any service with the same brand name.

Treat denial as information to resolve

missing_permission calls for authority review; workspace_key_required calls for the correct scope; connections_not_configured or mail_not_configured calls for operator setup; a plan or budget denial calls for explicit workspace decisions. Do not automatically switch to another provider, broader key or paid plan because a documented route rejected the request. Provider uncertainty after execution is a different issue and needs the saved operation record. Surface the specific stage and proposed remedy so the owner can decide the smallest necessary change.

Build a preflight that stays read-only

For a concrete task, inspect capabilities, caller identity and relevant billing or resource status, then propose the next supported action. Do not use a real send, purchased number or container creation as a readiness probe. Your next step is a fixture matrix for provider disabled, missing allowance, missing permission and fully ready states, with distinct user-facing explanations for each.

Sources & verification

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

• Lupin introduction and capability discovery ↗Checked 2026-11-05
• Lupin MCP provider failures ↗Checked 2026-11-05
• Lupin connections catalog ↗Checked 2026-11-05
• Lupin billing ↗Checked 2026-11-05

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