Can any MCP client deploy through SpringRoll?
A compatible client needs remote streamable HTTP support and an authorization flow accepted by SpringRoll. Point it at the public MCP endpoint, discover the available tools and authorize the workspace work you intend to perform. The protocol connection does not grant a new role or allow an agent to record a human approval decision.
The connection catalog includes Claude Code, Codex CLI, Claude Desktop, ChatGPT and Cursor instructions. Client availability and account entitlements can change. Follow the specific setup shown in the current catalog and the client's documentation rather than assuming that every product called an MCP client supports the same transport, callback and interactive flow.
https://springroll.dev/api/mcpStep 1: choose a connection your client supports
Use the client-specific command or settings fields from the setup catalog. CLI clients register the remote URL; clients with connector settings usually ask for a name, server URL and authorization method. Use the public SpringRoll endpoint that the client can actually reach. A localhost address in a hosted client refers to a different machine from your development laptop.
For Claude Code and Codex, the dedicated guides show the source commands and troubleshooting specific to each client. For other clients, check transport support before attempting the deployment. Registering a private-use OAuth callback scheme without a dot is refused by SpringRoll; use a supported HTTPS, loopback or reverse-domain callback rather than disabling the redirect checks.
Step 3: ask for a reviewable deployment
Once connected, ask the agent to inspect the project, production build and runtime needs. Supply the accountable owner and support contact. Review which workspace owns the application, whether it uses Direct to Production or Staged and which environment the agent will target. The default workflow is Direct; configure review requirements before a release if it should follow the staged path.
The agent needs the real source bundle or repository and a build that fits an available workload. List external services, environment variable names, persistent storage and background work. Keep credential values outside the conversation and client bundle. If the app's architecture is unsupported, stop the deployment attempt and resolve that fit rather than asking the agent to claim success anyway.
Prepare this project for SpringRoll. Check the build, workspace, owner and deployment workflow; tell me the target environment, then deploy and follow the build to its actual result.Step 4: follow the actual deployment status
A deployment request can return while a build is still queued or running. Keep the application, release and deployment references, then follow the returned status to READY or a terminal failure. The API reference describes polling and safe retries. Avoid interpreting a successful submission response as proof that the application is available to users.
On a failure, inspect the build error or policy reason and preserve its correlation reference. Correct the source or configuration and submit an appropriate new release. On a blocked approval, identify the person who must decide and show the required action. Repeating the same request does not turn an agent into a human reviewer or increase the authorized member's role.
Why the agent cannot approve its own work
The member's authorization permits actions within that member's role, while SpringRoll keeps human decisions separate. Deployment workflow reviews, data access and other governed changes follow the applicable approval rules. An agent may prepare the request and explain what is waiting; it cannot record the human approval. This keeps the decision attributable to a person responsible for the consequences.
Direct to Production still has requirements even when a separate release approval is not part of its workflow. Ownership, runtime configuration, data scope and launch audience remain decisions to verify. Keep the distinction visible in prompts: asking the agent to deploy an eligible app is different from asking it to grant broader company data or approve a scope increase.
Verify what a colleague can open
After READY, open the deployment and complete the app's core task. Check the result against a fictional fixture, then choose the intended audience and share the correct SpringRoll launch link. Verify the environment with an allowed user and a separate denied user. A client session reporting a URL is not a substitute for those browser checks.
Complete the linked direct-access checks and record the owner, support contact and release tested. When the app later adds company data, verify its environment-specific grant and the behaviour of a denied or revoked request before expanding use.
Keep the connection useful after the first release
Refresh discovery when resuming an older session so tool names and request schemas come from the current server. Preserve the original deployment result when retrying supported writes, and use the documented error envelope to distinguish a permission issue from a transient failure. Remove an authorization when it is no longer needed rather than leaving a dormant personal connection as the team's operational dependency.
The endpoint is one part of the workflow. Your project retains the source, SpringRoll retains the release and deployment record, and the owner remains accountable for the running app. Link the changelog and current API reference in your team's operating notes so future maintainers can review changes without reconstructing the original chat.