Any client that implements MCP Streamable HTTP and OAuth discovery can connect to STACK. A regular customer session currently discovers 131 public tools.
Connect the service and approve the fleet policy before starting automated work. The approved provisioner enrolls workers with their own keys. A worker uses its key to obtain a short-lived MCP session, then calls stack_start_mission with the job’s exact access and limits.
Use the returned Passport for calls through STACK. Routine allowed calls require no additional approval. Call stack_renew_mission to continue the same job without resetting its allowance. The client can obtain another session and reconnect with the worker’s key when its MCP session expires.
Interactive OAuth signs the client in as a member. Fleet execution uses the enrolled worker’s identity. Use a client or application runtime that can present the worker’s session token for this flow.
An owner OAuth session resolves to operator scope. A member OAuth session carries the member ID and applies the member's role and connection restrictions. Do not share an operator API key when you need per-user attribution.
MCP OAuth and API-key sessions normally do not carry an agent ID. Use a Passport or agent JWT when the API request must run as an agent. Keep separate client sessions when separate people or roles need separate attribution.
The client calls tools/list after it connects. Treat that response as the authority for tool names, descriptions, and input schemas. Platform-staff tools are not advertised to customer sessions.
A backend without an interactive browser can send the operator API key as Bearer authentication. The key has operator-wide access, so keep it in the service secret store and do not use this fallback for a human client that supports OAuth.
See MCP Setup, Authentication Troubleshooting, and Tool Reference.