Ankra

get_object_cost

Read-only

Read what one object of the organisation costs - a cluster, a namespace, a stack, an application, a cloud credential or a project - the same projection GET /org/cloud-cost/objects/{kind}/... serves. kind picks the object. cluster, namespace (give namespace) and stack (give stack_name) read one cluster: the selected one, or cluster_id when no cluster is selected (a cluster_id that is not the selected cluster is refused). application (give application_id), credential (give credential_id) and project (give project_id) read every cluster behind the object. Returns, in the organisation's display currency and minor units: monthly_cents (the run rate at the latest snapshot, times the hours in a month), idle_pct (the share of the run rate that is unrequested capacity - requests, not usage; clusters and credentials only), share_of_fleet_pct, confidence, the open cloud waste, trend_30d (cents per UTC day over 30 days) and, per cluster and per namespace, the figures behind it. null is unknown, not zero: priced false carries unpriced_reason, and a day, cluster or namespace nobody metered is null. coverage_incomplete true means monthly_cents is a floor, and each cluster's own coverage_incomplete says which cluster made it one. A namespace marked shared also runs another application and is counted whole. List-price estimates, not the bill. Read-only; use get_namespace_cost_history for a cluster's namespaces over time.

Input Schema

Name	Required	Description
`kind`	Yes	The kind of object: cluster, namespace, stack, application, credential or project.
`namespace`	No	The Kubernetes namespace, for kind namespace.
`cluster_id`	No	UUID of the cluster, for kind cluster, namespace or stack. Leave it out when a cluster is selected; one that is not the selected cluster is refused.
`project_id`	No	UUID of the project, for kind project. list_projects has the ids.
`stack_name`	No	The stack's name, for kind stack.
`credential_id`	No	UUID of the cloud credential, for kind credential.
`application_id`	No	UUID of the application, for kind application.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 14, 2026

changedInput schema / properties / kind / description

Previous value: -"The kind of object: cluster, namespace, stack, application or credential."New value: +"The kind of object: cluster, namespace, stack, application, credential or project."

changedInput schema / properties / kind / enum

Previous value: -[
-  "cluster",
-  "namespace",
-  "stack",
-  "application",
-  "credential"
-]New value: +[
+  "cluster",
+  "namespace",
+  "stack",
+  "application",
+  "credential",
+  "project"
+]

addedInput schema / properties / project_id

Added value: +{
+  "description": "UUID of the project, for kind project. list_projects has the ids.",
+  "type": "string"
+}

First observedOct 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With only readOnlyHint available, the description carries substantial extra context: display currency and minor units, null-vs-zero semantics, unpriced_reason, coverage_incomplete meaning monthly_cents is a floor, shared namespaces being counted whole, and that figures are list-price estimates rather than the bill. It also discloses the refusal behavior tied to cluster selection.

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?

Purpose and the kind-to-identifier mapping are front-loaded and every clause carries information, but it is a single dense paragraph and the return-value enumeration is packed tightly enough to be hard to scan.

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 7-parameter tool with no output schema, it explains the return payload, units, null and coverage semantics, and access restrictions. An agent has everything needed to choose the right kind and interpret the result honestly.

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 would be 3, but the description adds real meaning: kind is the discriminator, cluster/namespace/stack resolve to a single cluster with a selection fallback, while application/credential/project fan out across every cluster behind them. That fan-out rule is not derivable from the schema alone.

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 (read) and resource (cost of one object) and enumerates every accepted kind, so the scope is unambiguous. It also distinguishes itself from get_namespace_cost_history, which it explicitly names as the alternative for namespace histories over time.

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 maps each kind to the identifier it expects (namespace, stack_name, application_id, credential_id, project_id) and states the refusal condition for a cluster_id that is not the selected cluster. It names one alternative explicitly, but never contrasts itself with the closely related get_cluster_cost and get_stack_cost siblings.

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?