Skip to main content
Glama
Sign In

Ankra

by ai.ankra
OverviewDiscussionsAdmin

Rollout stack profile version

rollout_stack_profile_version
Destructive

Update the stacks deployed from a stack profile to a published version, in place (the twin of ankra stack-profiles rollout): the same stack on each cluster gets the version's contents and its workloads roll, keeping the non-secret inputs it was last applied with. Pick targets with clusters or all, and only_outdated for the ones behind. A member the version no longer lists is removed only if the profile put it there or it is named in confirmed_member_removals; otherwise that target is refused and left unchanged. Run with dry_run first to see what each target would remove. Stops at the first failing target unless continue_on_error. Requires stacks.write on every target cluster.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "rollout_stack_profile_version"
  }
}

Input Schema

NameRequiredDescriptionDefault
allNoTarget every deployment of the profile.
dry_runNoReport what each target would remove and change nothing.
versionNoThe version to roll out; defaults to the profile's current version.
clustersNoTarget cluster names or ids, from list_stack_profile_deployments. Give this or all.
parametersNoInput values as {name, value}. A secret input takes a ${SECRET_SLOT:<id>} reference, never a literal secret.
profile_idNoThe stack profile id (UUID) from list_stack_profiles. Give this or profile_name.
profile_nameNoThe stack profile's exact name, instead of profile_id.
only_outdatedNoOnly update deployments behind the version.
continue_on_errorNoKeep going after a target fails.
confirmed_member_removalsNoMembers the person confirmed may be removed, as cluster:kind/name (kind addon, manifest or application); kind/name alone with a single target.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial behavior beyond the destructive=true annotation: it rolls workloads in place, preserves previously applied non-secret inputs, refuses removal of members not owned by the profile unless confirmed, stops on first failure unless continue_on_error, and requires stacks.write on every target. This is strong disclosure for a destructive mutation tool.

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

Conciseness4/5

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

The description is front-loaded with the core action and then layers safety, targeting, and error behavior. It is dense but every sentence contributes operational information; the main drawback is that it is a long single paragraph rather than visibly structured.

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

Completeness5/5

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

For a destructive 10-parameter tool with no output schema, the description covers target selection, versioning, secret handling, removal safeguards, dry-run preview, failure behavior, and authorization. Nothing critical for correct invocation appears to be missing.

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 100%, so the baseline is 3, but the description adds meaningful semantics: clusters/all are target selectors, only_outdated filters behind targets, dry_run previews removals, and confirmed_member_removals governs whether unlisted members may be removed. It also clarifies that non-secret inputs are retained from the last application.

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?

States a specific verb and resource: update stacks deployed from a stack profile to a published version, in place. It also distinguishes itself from related operations by calling itself the twin of `ankra stack-profiles rollout`, so an agent can tell it apart from siblings like redeploy_stack or publish_stack_profile_draft.

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

Usage Guidelines4/5

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

Gives clear targeting guidance: use clusters or all, only_outdated for deployments behind the version, and dry_run first to preview removals. It also states the permission prerequisite (stacks.write). It does not explicitly name alternative tools, but the operational context is clear.

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

All Ankra toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources