Ankra

apply_cluster_manifest

Destructive

Apply an ImportCluster YAML declaratively (the twin of ankra cluster apply): the cluster named in metadata.name is created if it does not exist, and every stack the manifest names is created or REPLACED by its definition there. Stacks the manifest does not name are left untouched. A member (add-on, manifest, application) of a named stack that the manifest no longer lists would be removed, so such a removal is refused, with nothing written, naming the members, unless confirmed_member_removals names each one or prune is true: a manifest exported before those members were added looks exactly the same. Read the current definition with export_cluster_iac first and validate with validate_cluster_manifest. Moving the cluster to a different GitOps repository or branch is refused until allow_repoint is true (and allow_repoint_destroying_data when PersistentVolumeClaims would be pruned). For one stack at a time prefer create_stack / update_stack.

Input Schema

Name	Required	Description
`prune`	No	Confirm every removal this apply makes (default false). Only when the user said the manifest is the complete, current definition of the stacks it names; otherwise name the members in confirmed_member_removals.
`cluster_id`	Yes	Ankra cluster id (UUID) the call targets. Discover ids with list_clusters.
`allow_repoint`	No	Acknowledge that the manifest moves the cluster to another GitOps repository or branch, rewriting the files there (default false).
`manifest_yaml_base64`	Yes	The ImportCluster YAML (kind: ImportCluster, metadata.name, spec.stacks and optionally spec.git_repository), base64-encoded, at most 2 MiB. Inline `manifest` and `configuration.values` blocks are accepted; file references (from_file) are refused.
`confirmed_member_removals`	No	Members, as kind/name (kind addon, manifest or application), the user confirmed this apply may remove from the stacks it names because the manifest no longer lists them. Send only after the apply was refused naming them and the user agreed to each.
`allow_repoint_destroying_data`	No	The second acknowledgement required when the cluster holds PersistentVolumeClaims the repoint would prune (default false).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

addedInput schema / properties / confirmed_member_removals

Added value: +{
+  "description": "Members, as kind/name (kind addon, manifest or application), the user confirmed this apply may remove from the stacks it names because the manifest no longer lists them. Send only after the apply was refused naming them and the user agreed to each.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / prune

Added value: +{
+  "description": "Confirm every removal this apply makes (default false). Only when the user said the manifest is the complete, current definition of the stacks it names; otherwise name the members in confirmed_member_removals.",
+  "type": "boolean"
+}

First observedOct 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only say destructive=true; the description goes much further by describing replace semantics, the untouched-stack guarantee, the fact that refusals write nothing, that refusals name the affected members, and the PVC-pruning second acknowledgement. This is precisely the context an agent needs to avoid a data-destroying call.

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?

Front-loaded with the effect and free of filler, but it is one dense paragraph with long semicolon-chained clauses, especially the member-removal sentence, which is harder to parse than it needs to be. Content earns its place; structure could be split for scannability.

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 destructive mutation with no output schema and full annotation coverage, it covers preconditions, refusals, and confirmation flows thoroughly. The remaining gap is the outcome side: it does not say what a successful apply returns or whether it is synchronous, so an agent cannot predict the result shape.

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 already 100%, so baseline is 3, but the description adds real decision logic: prune means 'the manifest is the complete current definition' while confirmed_member_removals is the targeted alternative sent only after a refusal, and allow_repoint_destroying_data is framed as the second-level ack. It does not add format detail for manifest_yaml_base64, but the schema covers that.

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 ('Apply an ImportCluster YAML declaratively') and immediately enumerates the concrete effects: cluster created if absent, named stacks created or replaced, unnamed stacks untouched. It also differentiates itself from siblings by citing create_stack / update_stack for single-stack work.

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?

Explicitly says to read state with export_cluster_iac first, validate with validate_cluster_manifest, and use create_stack / update_stack when touching one stack at a time. It also gives the exact condition selecting prune vs confirmed_member_removals and the two acknowledgements needed for a GitOps repoint.

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

All Ankra tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?