SpringRoll MCP Server

Returns an application's registry record: metadata, lifecycle stage, risk score, and whichever of the optional sections you ask for. No secrets are included. Sections, all returned by default: • `source`: repository or uploaded bundle, and `cannotBuildReason` when a deploy would be refused for want of a source • `history`: recent releases and deployments • `status`: each environment's current deployment, outstanding approvals, and usage. This answers "where is my app up to?" • `grants`: data access grants and dependencies Pass a narrower `include` when you only need part of it; each section costs a query.

Lists applications in this organization, newest first. Use `search` to find one by name or slug.

Queue one premium icon draft from the app's reviewed purpose. Requests are limited and deduplicated. Artwork never blocks deployment or publishes itself.

Read a private app listing draft and available artwork. Does not publish or expose the app.

Save listing copy and selected image IDs to a private draft. Read the revision first. Use factual copy and real, reviewed screenshots. Only the owner or admin can publish in SpringRoll.

Upload a real screenshot or app icon as base64 PNG, JPEG, or WebP (8 MB maximum). Metadata is stripped. Images remain private until selected in an owner-published snapshot. Never upload confidential screen content.

Attaches the conversation that produced this application to its record, as reference for whoever maintains it next and for the reviewer who has to approve it. Ask the user before calling this, every time. The transcript is STORED and is READABLE BY ANYONE who can see the application record. SpringRoll scrubs credentials it recognises before writing (agent tokens, cloud keys, private keys, connection strings, and assignment lines whose key looks like a secret), but that scrubbing is best-effort and cannot be complete. If the conversation contained a real secret, do not record it. Send turns in order. Keep `sessionKey` stable across calls for one build so they join up; retrying with the same key and turn indexes overwrites rather than duplicating.

Updates App Portal metadata: description, icon, tags, department, support contact, and data classification. Visibility is deliberately not editable here, because widening an audience requires an approval request (sec. 15.4).

Returns an approval request with its assigned reviewers, decisions so far, and the policy snapshot taken at submission. Poll this to find out whether a release has been approved.

Submits an approval request of any supported type: UAT_PROMOTION, UAT_SIGN_OFF, PRODUCTION_PROMOTION, VISIBILITY_CHANGE, OWNERSHIP_TRANSFER, RETIREMENT, DOMAIN_CHANGE, or ROLLBACK. **An agent may submit but never decide**: SpringRoll requires a human approver, and an agent token cannot approve its own request. Confirm with the user before calling this. It creates review work for named people. Type-specific behaviour: • `PRODUCTION_PROMOTION`: this does NOT deploy. It asks. `releaseId` defaults to the application's latest release, and `targetEnvironmentType` to 'production'. Once approved, call springroll.deploy.promote. • `UAT_PROMOTION`: `targetEnvironmentType` is required, 'uat' (or 'development' where Development needs approval). An approval only unlocks the environment it names. • `UAT_SIGN_OFF`: `targetEnvironmentType` defaults to 'uat'. • `ROLLBACK`: `justification` and `targetEnvironmentType` (the environment to roll back) are required. Put the deployment to restore in `payload.targetDeploymentId`; it defaults to the last successful one. • `RETIREMENT`: `justification` is required. • Every other type takes no `targetEnvironmentType`.

Returns the status of a data access request: REQUESTED, APPROVED, REJECTED, REVOKED, or EXPIRED, with the fields actually approved. Approved fields are often narrower than requested, and a row filter may restrict which rows the application can see at all.

Without `dataProduct`, lists the governed data products this organization publishes: what each one holds, who owns it, and how sensitive it is. With `dataProduct`, returns that product's schema: its datasets, the available fields with their types and sensitivity, the business glossary its owner wrote, and what the underlying source can compute. Read this before requesting access, so you request the fields the application actually needs. Either way you learn the *kind* of system behind a product (so you know, for example, which query capabilities a source supports) but never a host, a credential, a table name, or a connection string. Request access with springroll.connect.request_access; a data owner must approve it.

Requests access to a data product for one environment, naming the exact fields the application needs. A data owner must approve, and may narrow the field list or add a row filter before doing so. Nothing is readable until then. You never receive a credential: an approved grant lets the deployed application ask questions through the SpringRoll Connect gateway, which enforces the grant on every request.

Returns the organization, identity, and permissions this agent token acts as, together with the deployment runtimes configured for it. Call this first: it tells you which tenant you are in, what you are allowed to do, and whether a deployment can actually land. It never returns credentials.

Registers the project if it is new, attaches whatever source you give it, and deploys it using the application's Deployment workflow. Direct applications go to Production; Staged applications go to Development. Returns the live URL, or a deployment id to poll if the build is still running. **You do not decide whether this project needs git.** Send what you have and SpringRoll works it out: • a pushed git remote → pass `repositoryUrl` (and `ref` if not the default branch) • no remote, or uncommitted work → pass `archive`, a base64 tar+gzip of the source: tar --exclude=node_modules --exclude=.next --exclude=.git --exclude='.env*' \ -czf - . | base64 -w0 • both → SpringRoll builds from git, and falls back to your files if the ref cannot be resolved (an unpushed branch, typically) • neither, on an app that already exists → redeploys its current source Upload SOURCE, not build output: SpringRoll runs the build. node_modules, .next, dist, build, out, coverage and .log files are dropped automatically and reported. Every .env file and .git/ is REFUSED outright, naming the offending path: configuration belongs in SpringRoll, not in the bundle. Upload limits are about 3 MB compressed on the wire (a platform request-body cap, not a preference), 20 MB expanded, 2000 files, 512 KB per file; a project past them should pass `repositoryUrl` instead, which SpringRoll clones directly with no size limit. Sending the same files twice is free, because bundles are addressed by content. Direct to Production skips workflow approvals but keeps production safety checks. Staged applications continue to use explicit promotion and approvals.

Promotes a tested deployment into the next environment (development -> uat, uat -> production). Reuses the already-built artifact rather than rebuilding, so the bytes that were tested are the bytes that ship. Promotion into an environment that requires approval will be refused until the approval exists. For production, submit the request first.

Returns a deployment's current status, refreshing it from the runtime provider when the build is still in progress. Statuses: QUEUED, VALIDATING, BUILDING, DEPLOYING, READY, FAILED, CANCELLED, SUPERSEDED, ROLLED_BACK. Poll this after deploying rather than assuming success. Pass `includeLogs` to get the normalised build and deploy log lines alongside the status. Do that once the status is FAILED, rather than guessing at the cause.

List only the authenticated member's SpringRoll feedback in the current organization, newest first. Use nextOffset for the next page.

Submit a bug report, idea, or other feedback about SpringRoll on behalf of the authenticated member. Do not include credentials. Reuse the idempotency key when retrying the same submission.

Scores where SpringRoll would place this application and what it would cost, without deploying or writing anything. It shares its implementation with springroll.deploy, so the receipt it returns is what a deploy right now would decide: the provider and plan, the estimated monthly cost range, every limit the plan carries, what was inferred rather than declared, and why each other candidate lost. It works before any provider account is connected. The ranking is computed from the public catalog alone and credentials never affect it: connecting an account changes only whether a plan is deployable, never how it ranks. Each ranked alternative carries its readiness and the action that unlocks it, so you can tell the user both what is recommended and what would deploy today. Use it to put the cost and the limits in front of the user before deploying, or to ask what-if questions by varying the placement hints.

Reports which governance policies an application would pass or fail for an environment. Send `manifest` (YAML or JSON) to validate a document without creating anything. Call this before springroll.deploy to avoid a rejected submission. Read the `springroll://manifest/example` resource for the document's shape. Send `application` instead to explain why an existing application cannot deploy or promote to `environmentType`, with specific remediation for each failing rule. Call this when a deployment is rejected with POLICY_BLOCKED. Send exactly one of the two.