Skip to main content

Launch the application

The Launch tab is the gate between "I'm setting this up" and "this is live." Behind the button is a checklist; nothing happens until every box is green.

What the UI does

Three sections on the Launch tab:

  1. Status banner — green "Ready to launch" if every check passes, red "Not ready to launch" with the count of remaining steps if not.
  2. Setup checklist — six rows, one per setup phase. Each shows COMPLETE or PENDING with a count (e.g. "Map tools to scopes — 96 unmapped — Pending").
  3. Activation preview — what your policy will look like at the moment of launch. Tool counts, mapped/public/unmapped, default role grants, viewer scopes, public tools.

When everything is green, the Activate button at the top lights up.

The checklist

StepRequired for activationWhat it checks
RegisterAlways green after registrationResource server row exists.
Tool inventoryAt least one toollast_successful_generation > 0.
Define scopesAt least one scopeoauth_scopes count > 0 for this RS.
Map tools to scopesNo unmapped toolsEvery tool from the latest scan generation has either a scope mapping or is_public = true.
Default roleDefault role exists and is enabledresource_server_access_policies.enabled = true AND default_role_id set.
ActivateAll five above are greencan_activate = true (computed).

The can_activate field is computed on the fly by GET /authsec/resource-servers/:id/setup — it's not stored. The same call returns the full checklist state.

The activation preview

Sourced from GET /authsec/resource-servers/:id/activation-preview. What the policy will look like the moment you launch:

{
"tool_counts": {"total": 101, "mapped": 5, "public": 1, "unmapped": 96},
"default_role_grants": [],
"viewer_scopes": [],
"first_time_user_grant": null,
"public_tools": ["actions_get"]
}

This is what the SDK will be enforcing in five seconds if you click Activate now. Read it carefully — it's the last preview before you commit.

What Activate does

POST /authsec/resource-servers/:id/activate:

  1. Re-runs the can_activate check. Bails with 409 if anything regressed since you loaded the page.
  2. Updates resource_servers with:
    • state = 'ready'
    • setup_completed_at = NOW()
    • setup_completed_by = <admin_user_id>
  3. Emits an audit event so the action shows up in audit logs.
  4. The SDK ScopeMatrixClient picks up the new policy on its next stale read (typically within 5 minutes; can be forced by restarting your MCP server).

The change is one-way logical but technically reversible: there's no Un-activate button, but you can rotate the introspection secret to force SDK calls to fail and effectively shut the integration down. For ongoing changes, edit on the Tools tab and the runtime picks them up.

Re-running activation after changes

You don't have to re-activate when you change scopes or mappings after launch. The state stays ready; the changes just propagate to the SDK on its next policy refresh.

What does require activation:

  • Going from needs_setupready for the first time.
  • After a scan rebuild from scratch (e.g. deleted all tools and rescanned), if can_activate regressed to false.

What state = ready changes at runtime

When the SDK fetches the policy and sees state = 'ready', enforcement is on. Before that, the SDK is technically running but the policy is empty — every tool call falls back to "no policy", which under PolicyModeRemoteRequired means 503. So in practice, activating is what turns the SDK from "always fail closed" to "enforce real policy."

The setup_completed_at timestamp is informational — drift events use it to know whether an event is post-activation (worth surfacing on the Monitor tab) or pre-activation (just admin housekeeping).

Troubleshooting

Activate is greyed out. The setup checklist tells you exactly which step is pending. Fix that step.

Activate fails with 409. can_activate regressed between page load and click — someone deleted a scope, unmapped a tool, or disabled the access policy in the meantime. Reload the page and check the checklist.

Activate succeeded but my MCP server is still 503ing. The SDK's policy cache hasn't refreshed yet. Either wait up to 5 minutes for the natural refresh, or restart your MCP server.

Auth scheme

EndpointAuth
GET /authsec/resource-servers/:id/setupAdmin JWT
GET /authsec/resource-servers/:id/activation-previewAdmin JWT
POST /authsec/resource-servers/:id/activateAdmin JWT

None of these are SDK-facing.