io.github.springrolldev/springroll

Tools

• springroll.app.get

  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.

  shallow
• springroll.app.list

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

  shallow
• springroll.app.record_prompts

  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.

  shallow
• springroll.app.update

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

  shallow
• springroll.approval.get

  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.

  shallow
• springroll.approval.submit

  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. Once approved, call springroll.deploy.promote. • `ROLLBACK` — `justification` is required, and `targetEnvironmentType` says which environment to roll back. Put the deployment to restore in `payload.targetDeploymentId`; it defaults to the last successful one. • `RETIREMENT` — `justification` is required.

  shallow
• springroll.connect.access_status

  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.

  shallow
• springroll.connect.data_products

  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, that a Notion-backed product cannot aggregate) 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.

  shallow
• springroll.connect.request_access

  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.

  shallow
• springroll.context

  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.

  shallow
• springroll.deploy

  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 — 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.

  shallow
• springroll.deploy.promote

  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.

  shallow
• springroll.deploy.status

  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.

  shallow
• springroll.placement.preview

  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.

  shallow
• springroll.policy.check

  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.

  shallow

Embed this server’s score

Tool count and median score across every tool in this server’s corpus — honest in a way a single cherry-picked tool’s badge wouldn’t be.

[![Vouch score](https://vouch.tools/api/servers/16af317d-57cf-41e0-af16-f6a9e3300db9/badge.svg)](https://vouch.tools/servers/16af317d-57cf-41e0-af16-f6a9e3300db9)