Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

set_cluster_agent_auto_upgrade

Turn automatic upgrades of the Ankra agent on a cluster on or off (the twin of ankra cluster agent auto-upgrade enable|disable and the portal's cluster settings). With them on, the fleet rollout applies each new agent release to this cluster as soon as it has no write execution running; with them off the rollout skips this agent until they are turned back on, which is how a team fences a cluster off from agent releases for a freeze window or a migration night. 'enabled' is required and must be given explicitly: both directions are deliberate. Read the current setting with get_cluster_agent_status (disable_auto_upgrade); upgrade_cluster_agent applies a release on demand whichever way the switch sits. Every change is recorded in the audit log with who made it, the previous and new setting and the reason when one is given. Requires agents.manage.

Input Schema

NameRequiredDescriptionDefault
reasonNoWhy the switch is being changed, in the operator's own words (a freeze window, a migration night, the end of one). Recorded on the change's audit row so the next person can see why the fence went up or came down. Optional.
enabledYestrue puts the agent back into the automatic fleet rollout; false fences it off until enabled again.
cluster_idNoUUID of the target cluster. Optional when a cluster is selected.
cluster_nameNoExact name of the target cluster. Optional when a cluster is selected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / reason
      Added value: +{
+  "description": "Why the switch is being changed, in the operator's own words (a freeze window, a migration night, the end of one). Recorded on the change's audit row so the next person can see why the fence went up or came down. Optional.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give the generic triple; the description adds the required permission (agents.manage), the audit-log behavior including who/previous/new setting/reason, and the fact that 'enabled' must be given explicitly because both directions are deliberate. That is substantial behavior beyond structured fields.

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 core action and its consequences, then alternatives, then audit/permission notes. Dense but every sentence carries operational information; slightly verbose in places but no filler.

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 simple boolean switch with 100% schema coverage and no output schema, the description covers effects, prerequisites, alternatives, and audit behavior. Nothing an agent needs to call it correctly is 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 real meaning: why 'enabled' must be explicit, what the reason field is for and where it lands (audit row), and the mutual exclusivity of cluster_id/cluster_name ('optional when a cluster is selected').

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 precise verb ('turn on or off') and resource ('automatic upgrades of the Ankra agent on a cluster'), and explicitly distinguishes itself from get_cluster_agent_status and upgrade_cluster_agent. An agent can identify the exact operation without opening the schema.

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?

It spells out the operational consequences of each direction (on = fleet rollout applies each new release; off = rollout skips this agent) and names the concrete scenarios (freeze window, migration night). It also routes the agent to the read and on-demand alternatives by name.

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