Install an add-on

Installs a catalog add-on at a scope: org, project, sandbox or atlas_workspace. Every install passes the same checks, in this order, each refusal with its code. The listing exists and the caller can see it in the org's catalog (addon_not_found otherwise), and the caller holds the kind's .manage at the scope (skills.manage, mcp.manage: at the org, on the project, or on the sandbox's project). Only then: the listing is not blocked or retired; the scope is one of its attachLevels; the org's policy allows it (community add-ons need the org's opt-in or an explicit allow); the org holds it (free, included in its plan, or bought: installing never buys); and nothing above the scope has switched it off. Today skills and MCP servers install on a project, one install of a listing per project. A resource is allocated, on a project (the default for its sandboxes) or one sandbox, by config.quantity, under resources.manage on the project (a sandbox's own project); posting again for the same scope changes its quantity. After the checks above, an allocation also needs, in this order: a quantity; a sandbox no more than its project's default (resource_exceeds_project); the org's allocations of the resource within what it bought (resource_quantity_exceeded); the plan's cap for it, and a plan with none refuses (resource_quota_not_set, resource_quota_exceeded); for a resource billed on use, the org's own cap (resource_org_cap_not_set, resource_org_cap_exceeded); and room on a host (addon_capacity_unavailable, 503). Plugins are not installable yet (501), every install and allocation is audited, and apps are added to an Atlas workspace from Atlas.

Path Parameters

Response Body