Ankra

get_fleet_cloud_cost

Read-only

Get the cloud cost rollup of the current project - or of one project, or the whole organisation, with project_id - the same figures the portal's Cost page shows. scope says what was read; by_project splits the organisation-wide read per project, with an unattributed bucket for spend stamped with no project, and partial true means RBAC hid clusters so every figure is a floor. Returns the projected month-end, month-to-date and monthly run-rate totals in the organisation's display currency, the split by provider (cluster count and the same three figures each), and the costliest clusters with their confidence level. Only clusters whose latest hourly snapshot is younger than a day contribute; has_data false with cluster_count 0 means nothing is priced yet, not that the fleet is free. It also carries a trend block over the last 30 days: the run rate at the start and now, and every day the set of priced clusters changed, naming the clusters that entered or left pricing - a coverage move, not spend; and an events block naming the biggest moves on the line (releases, node changes, stops and starts, executed decisions, coverage, resolved waste), each with how its delta was measured. available false means the block could not be read. Read-only. Use get_cluster_cost on a selected cluster for its per-namespace breakdown.

Input Schema

Name	Required	Description	Default
`project_id`	No	UUID of a project to read, or all for the whole organisation. Leave it out to read the project the conversation or token is in (the whole organisation while the organisation has no projects). list_projects has the ids.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

addedInput schema / properties / project_id

Added value: +{
+  "description": "UUID of a project to read, or all for the whole organisation. Leave it out to read the project the conversation or token is in (the whole organisation while the organisation has no projects). list_projects has the ids.",
+  "type": "string"
+}

First observedOct 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With only readOnlyHint=true set, the description carries the behavioral burden and does so exceptionally: partial=true means RBAC hid clusters so all figures are floors, has_data=false with cluster_count 0 means nothing is priced (not free), trend coverage changes are 'a coverage move, not spend', and available=false means the block was unreadable. It also explains the freshness rule (snapshots younger than a day).

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

Conciseness3/5

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

The purpose is correctly front-loaded, but the body is a sprawling single-paragraph run-on that mixes return-value detail, RBAC caveats, trend/event semantics, and the alternative tool in one block. Most content earns its place given no output schema, but bullet or sentence-level structure would make it far more parseable.

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 read-only tool with one optional parameter and no output schema, the description compensates for the missing schema almost completely: it enumerates the rollup figures, provider split, costliest clusters, trend block, and events block, plus every sentinel condition. An agent has enough to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single project_id parameter is already fully documented (UUID, 'all', omit-for-default). The description adds little syntax beyond noting scope semantics that the schema already conveys; baseline 3 is appropriate.

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 opening sentence names a specific verb and resource ('cloud cost rollup') and pins the scope precisely: current project, one project via project_id, or the whole organisation. It differentiates itself from the nearest sibling by pointing to get_cluster_cost for per-namespace detail. An agent can identify this tool 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 Guidelines4/5

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

It explicitly routes the agent to get_cluster_cost for a selected cluster's per-namespace breakdown and explains the default read scope when project_id is omitted. It doesn't survey the other cost siblings (get_stack_cost, get_namespace_cost_history, get_object_cost), so the alternative space is only partially mapped.

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?