Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

set_cluster_agent_resources

Resize the Ankra agent itself on a cluster: set its container's memory and CPU limits and requests. This is the fix for an ankra-agent that is OOMKilled at its memory limit (raise memory_limit, e.g. to "2Gi"); do not hand the user a helm or kubectl command for it. Ankra holds the sizing for the cluster, so every later agent upgrade and every reinstall renders it; an agent that accepts held sizing re-renders its own release at once, and an older one has its Deployment resized directly and keeps it through upgrades (the result's survives_agent_upgrades says whether that holds). Either way the agent restarts onto the new sizing, so the cluster reads as offline for a few seconds. Only the named members change; an empty string stops Ankra holding a member (the agent keeps its current value for it, so to change a value set a new one), and a call that matches what the agent already runs stores it without a restart. Requests are capped low on purpose (memory 128Mi-2Gi, CPU 50m-2) because the agent's old pod stops before the new one schedules and a request no node can place would leave the cluster without an agent; limits take memory 512Mi-16Gi and CPU 100m-8. A request above its limit is refused. Read the agent's current sizing with describe_resource on the Deployment ankra-agent in the agent's namespace, and its OOM history with get_events or get_pod_logs. Requires agents.manage.

Input Schema

NameRequiredDescriptionDefault
cpu_limitNoNew CPU limit, as a Kubernetes quantity (100m to 8), e.g. "1" or "500m", or an empty string to stop holding it.
cluster_idNoUUID of the target cluster. Optional when a cluster is selected.
cpu_requestNoNew CPU request, as a Kubernetes quantity (50m to 2), or an empty string to stop holding it. Must not exceed the CPU limit. Usually leave unchanged.
cluster_nameNoExact name of the target cluster. Optional when a cluster is selected.
memory_limitNoNew memory limit for the agent container, as a Kubernetes quantity (512Mi to 16Gi), e.g. "2Gi", or an empty string to stop holding it. Raise this for an OOMKilled agent.
memory_requestNoNew memory request, as a Kubernetes quantity (128Mi to 2Gi), or an empty string to stop holding it. Must not exceed the memory limit. Usually leave unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / cpu_limit / description
      Previous value: -"New CPU limit, as a Kubernetes quantity (100m to 8), e.g. \"1\" or \"500m\"."New value: +"New CPU limit, as a Kubernetes quantity (100m to 8), e.g. \"1\" or \"500m\", or an empty string to stop holding it."
    • changedInput schema / properties / cpu_request / description
      Previous value: -"New CPU request, as a Kubernetes quantity (50m to 2). Must not exceed the CPU limit. Usually leave unchanged."New value: +"New CPU request, as a Kubernetes quantity (50m to 2), or an empty string to stop holding it. Must not exceed the CPU limit. Usually leave unchanged."
    • changedInput schema / properties / memory_limit / description
      Previous value: -"New memory limit for the agent container, as a Kubernetes quantity (512Mi to 16Gi), e.g. \"2Gi\". Raise this for an OOMKilled agent."New value: +"New memory limit for the agent container, as a Kubernetes quantity (512Mi to 16Gi), e.g. \"2Gi\", or an empty string to stop holding it. Raise this for an OOMKilled agent."
    • changedInput schema / properties / memory_request / description
      Previous value: -"New memory request, as a Kubernetes quantity (128Mi to 2Gi). Must not exceed the memory limit. Usually leave unchanged."New value: +"New memory request, as a Kubernetes quantity (128Mi to 2Gi), or an empty string to stop holding it. Must not exceed the memory limit. Usually leave unchanged."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the brief offline window, the held-sizing vs direct-resize distinction, survives_agent_upgrades, empty-string semantics, the deliberate request caps and their rationale, request-above-limit refusal, and the agents.manage permission requirement. No contradiction with readOnlyHint=false/destructiveHint=false.

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 the primary use case, and every sentence carries real information. It is, however, a dense single block heavy with nested parentheticals, which costs some parseability.

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 complex, annotation-light mutation with no output schema, the description covers permissions, side effects (restart/offline blip), sizing semantics, validation rules, and even names the result field survives_agent_upgrades. 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 genuine meaning beyond the schema: the empty-string-stops-holding behavior and why changing a value requires setting a new one, plus the reasoning behind the request caps and the request-must-not-exceed-limit rule.

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+resource: resizing the Ankra agent's container limits/requests on a cluster. It clearly separates this from siblings like upgrade_cluster_agent, set_cluster_agent_auto_upgrade, and scale_deployment by naming the exact object being resized.

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 frames the trigger (an ankra-agent OOMKilled at its memory limit, raise memory_limit) and the anti-pattern (do not hand the user a helm or kubectl command). It also routes to describe_resource for current sizing and get_events/get_pod_logs for OOM history.

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