Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

get_cost_reconciliation

Read-only

Read what each cloud credential's provider billed for a month against Ankra's estimate for the same clusters - the document GET /org/cloud-cost/reconciliation serves. month is a UTC calendar month as YYYY-MM, not in the future (the last closed month when omitted; for the running month both sides are month to date). Per credential: state (absent when no billing document was imported: unknown, not zero), the imports with each attempt's reason, and in the invoice's own currency and minor units invoice_minor (tax_minor and credit_minor set apart), matched_minor placed on clusters and unmatched_minor not, estimate_minor for those clusters converted at estimate_fx, and difference_pct, null with difference_reason saying why when it cannot be stated. difference_caveat names billed lines in priced categories placed on no cluster. null is unknown, never zero or agreement. Requires billing.read. Read-only.

Input Schema

NameRequiredDescriptionDefault
monthNoUTC calendar month as YYYY-MM, not in the future. Omit for the last closed month.
project_idNoUUID of a project to reconcile, or all for the whole organisation. Leave it out to read the project the conversation or token is in. Read for one project, only credentials whose invoice places a line on one of its clusters are listed, with invoice_withheld true: the invoice-wide totals and unplaced lines are left out because an invoice spans other projects, and matched_minor and difference_pct are that project's clusters alone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"UUID of a project to reconcile, or all for the whole organisation. Leave it out to read the project the conversation or token is in. Only the billed clusters narrow: a credential's documents and invoice totals are the organisation's, because an invoice is."New value: +"UUID of a project to reconcile, or all for the whole organisation. Leave it out to read the project the conversation or token is in. Read for one project, only credentials whose invoice places a line on one of its clusters are listed, with invoice_withheld true: the invoice-wide totals and unplaced lines are left out because an invoice spans other projects, and matched_minor and difference_pct are that project's clusters alone."
  2. Changed1 schema field changed
    • addedInput schema / properties / project_id
      Added value: +{
+  "description": "UUID of a project to reconcile, or all for the whole organisation. Leave it out to read the project the conversation or token is in. Only the billed clusters narrow: a credential's documents and invoice totals are the organisation's, because an invoice is.",
+  "type": "string"
+}
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond readOnlyHint=true, it declares the required billing.read permission, explains that null means unknown rather than zero or agreement, states when state is absent, specifies invoice currency and minor units, and discloses project-level invoice withholding behavior. It also describes difference_caveat and difference_reason, which are important caveats for interpreting the data.

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?

The purpose is front-loaded and most clauses carry necessary semantic detail for a complex reconciliation tool with no output schema. However, it is a dense run-on paragraph that would be easier to scan if structured into shorter sentences or bullets.

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?

Despite having no output schema, the description enumerates the key return fields per credential, including state, imports, invoice_minor breakdowns, matched/unmatched amounts, estimate conversion, difference_pct, and null semantics. Combined with the permission requirement and read-only nature, it gives an agent enough context to call and interpret the tool correctly.

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?

With 100% schema description coverage, the schema already carries the parameter documentation, so the baseline is 3. The description adds some nuance about month-to-date behavior for the running month, but much of the month and project_id explanation repeats what is already in the schema.

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 starts with a specific verb and resource: reading each cloud credential's provider-billed amount against Ankra's estimate, and names the backing document endpoint. This clearly distinguishes reconciliation from sibling cost tools such as get_cloud_savings or get_cluster_cost.

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 concrete usage context for month, including the YYYY-MM format, the no-future-months constraint, the last-closed-month default, and month-to-date behavior for the running month. It also explains project_id scoping, but does not explicitly name alternative tools or when not to use this one.

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