SpringRoll

Submit an approval request

springroll.approval.submit

Idempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`payload`	No	Type-specific detail, e.g. { visibility: 'TENANT' }, { newOwnerMembershipId: '…' }, or { targetDeploymentId: '…' } for a rollback.
`releaseId`	No	Release this concerns. For PRODUCTION_PROMOTION, defaults to the latest release.
`application`	Yes	Application slug or id.
`requestType`	Yes
`justification`	No	Why this should happen. Shown to reviewers. Required for ROLLBACK and RETIREMENT, and at least 10 characters when required.
`idempotencyKey`	Yes	Required. A stable, caller-generated key. Retrying with the same key returns the original result instead of creating a duplicate.
`targetEnvironmentType`	No	Canonical environment class. SpringRoll promotes development -> uat -> production.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral context beyond the annotations: it reveals the human-approval requirement, explicitly forbids agent self-approval, states that this is not a deployment action, and documents type-specific defaults and required fields. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a core workflow constraint up front and a compact bulleted list of type-specific behaviors. Every sentence adds information an agent needs before calling, and there is no redundant restatement of the schema or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool with 8 request types, nested payloads, and no output schema, the description covers the most critical operational cautions, defaults, and required fields. However, several supported types (e.g., UAT_PROMOTION, OWNERSHIP_TRANSFER, DOMAIN_CHANGE) lack explicit behavioral guidance, and the description does not indicate what the response contains after submission. These are meaningful but not severe gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 88%, so the schema already carries most parameter meaning. The description adds value by explaining type-specific semantics: releaseId defaults to the latest release for PRODUCTION_PROMOTION, targetDeploymentId indicates the deployment to restore for ROLLBACK, and justification is required for ROLLBACK and RETIREMENT. It does not detail payload requirements for every request type, but the schema examples help fill that gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Submits') and resource ('approval request'), enumerates all supported request types, and clearly differentiates this submit action from the sibling approval.get and deploy.promote tools. It leaves no ambiguity about what the tool accomplishes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guardrails: an agent may submit but never decide, user confirmation is required before calling, and it creates review work for named people. It also clarifies that PRODUCTION_PROMOTION does not deploy but merely asks, and directs the agent to call springroll.deploy.promote after approval, which routes away from the wrong sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SpringRoll tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: app metadata, approvals, connect grants, deployments, placement, and policy are cleanly separated by namespace and verb. Even close pairs like placement.preview vs deploy or approval.submit vs deploy.promote are explicitly differentiated in their descriptions.

Naming Consistency4/5

Most tools follow a clear springroll.<area>.<verb> pattern (app.get, approval.submit, deploy.promote, policy.check). The pattern is weakened by a few noun-style or verb-only exceptions: springroll.context, springroll.deploy, and connect.data_products do not fit the same verb shape.

Tool Count5/5

Fifteen tools is at the upper bound of a well-scoped set, and each tool covers a distinct, justified part of the deployment and governance lifecycle. The count is appropriate for a platform that spans apps, approvals, data access, deployment, placement, and policy.

Completeness4/5

Core workflows are well covered: deploy, promote, poll status, preview placement, check policy, request/check data access, and submit/get approvals. Minor gaps exist around executing rollbacks or retirements after approval and listing/cancelling deployments, but these do not break the main agent workflows.

Resources

Need Help?