Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

update_cost_autopilot

Change the organisation's cost autopilot policy, one project's defaults layer, or one cluster's tier - one of the three per call. For a project, give project_id with defaults (the project's clusters take those tiers over the organisation's, under any cluster override) or clear_project_defaults true. For the policy, name only what changes: defaults maps the environment kinds to change to tiers (kinds left out keep theirs), quiet_hours and notification_route_id are set or cleared with null. For one cluster, give cluster_id with a tier and the reason its cards will show (optionally expires_at), or clear_override true to return it to its environment's tier. Needs billing.manage and clusters.write; every change is audited, and the savings cards carry the new tier from their next read. Reversible by setting the previous values back (read get_cost_autopilot first).

Input Schema

NameRequiredDescriptionDefault
tierNoThe tier to put the cluster in.
reasonNoWhy, as the cluster's cards will show it: 3 to 500 characters.
defaultsNoEnvironment kinds to change and their tiers.
cluster_idNoThe cluster whose tier to set or clear, from get_cost_autopilot.
expires_atNoRFC 3339 time the override stops applying; omit for never.
project_idNoUUID of a project whose defaults layer to set (with defaults) or clear (with clear_project_defaults). The project's clusters take these tiers over the organisation's defaults, under any cluster override. list_projects has the ids.
quiet_hoursNoWhen the autopilot starts no change of its own; null clears.
clear_overrideNoReturn the cluster to its environment's tier.
notification_route_idNoA notification route of the organisation for the autopilot's pre-notices; null clears.
clear_project_defaultsNoWith project_id: remove the project's defaults so its clusters follow the organisation's again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / clear_project_defaults
      Added value: +{
+  "description": "With project_id: remove the project's defaults so its clusters follow the organisation's again.",
+  "type": "boolean"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "description": "UUID of a project whose defaults layer to set (with defaults) or clear (with clear_project_defaults). The project's clusters take these tiers over the organisation's defaults, under any cluster override. list_projects has the ids.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With annotations already covering readOnly=false and destructive=false, the description adds substantial context: required permissions, auditing of every change, propagation timing ('savings cards carry the new tier from their next read'), reversibility by restoring previous values, and the one-of-three constraint. It is consistent with the idempotentHint=false annotation by not claiming repeated calls are safe or idempotent.

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?

Despite covering three modes and ten parameters, every sentence is front-loaded and earns its place, moving from overall purpose to per-mode instructions to prerequisites and reversibility. There is no filler or repetition.

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 mutation tool with ten parameters, nested objects, three distinct modes, and no output schema, the description is complete enough: it covers all modes, parameter interactions, permissions, audit behavior, propagation, and reversibility. Nothing essential for correct invocation 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 baseline is 3, but the description goes beyond the schema by explaining how parameters combine per mode: project_id with defaults or clear_project_defaults, cluster_id with tier/reason/expires_at or clear_override, and the fact that defaults only changes named environment kinds while omitted ones keep theirs. It adds meaningful interaction context beyond individual schema descriptions.

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 opens with a specific verb and three concrete targets: the organisation's cost autopilot policy, a project's defaults layer, or a cluster's tier. It explicitly states 'one of the three per call,' which removes ambiguity about scope and distinguishes it from the sibling get_cost_autopilot used only for reading.

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?

It gives clear mode selection for each target and states prerequisites ('Needs billing.manage and clusters.write') plus a prerequisite to read first for reversibility ('read get_cost_autopilot first'). However, it does not explicitly exclude or compare against other sibling tools like update_cost_settings or set_cost_budget, which would be needed for a 5.

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