Skip to main content
Glama
talonicdev

talonic-mcp

Official
by talonicdev
OverviewSchemaRelated ServersScoreDiscussions(1)
TypeScript
Remote

Get Talonic Credit Balance

talonic_get_balance
Read-only

Retrieve your current Talonic credit balance, EUR value, and 30-day burn rate to confirm budget headroom before kicking off large batches or re-extractions.

Instructions

STATUS: stable.

Read the user's current Talonic credit balance, EUR value, 30-day burn rate, projected runway, tier, and next-tier-reset timestamp. Use this to make budget- aware decisions before kicking off large batches or re-extractions.

USE WHEN:

  • The user asks how many credits or how much budget they have left.

  • You are about to run a large or expensive operation (batch extract, re-extract many documents) and want to confirm budget headroom first.

  • The user asks how long their balance will last at the current rate.

DO NOT USE WHEN:

  • The user just wants the per-call cost of a single extraction (that is already on the talonic_extract response under cost).

  • The user wants to top up credits (route them to the dashboard; auto top-up is guarded by a separate scope).

RESPONSE SHAPE:

  • balance_credits: current credit balance.

  • balance_eur: current balance in EUR (rounded to two decimals).

  • burn_rate_30d_credits: total credits consumed in the trailing 30 days.

  • projected_runway_days: days of runway at the current 30-day average burn. -1 indicates no consumption in the trailing window (cannot compute runway).

  • tier: API tier of the workspace (free, pro, enterprise, etc.).

  • tier_resets_at: ISO 8601 timestamp of the next monthly tier reset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
balance_creditsYesCurrent credit balance.
balance_eurYesCurrent balance in EUR (two decimals).
burn_rate_30d_creditsYesTotal credits consumed in the trailing 30 days.
projected_runway_daysYesProjected days of runway at the current 30-day average burn. `-1` when burn is zero (cannot compute).
tierYesAPI tier of the workspace.
tier_resets_atYesISO 8601 timestamp of the next monthly tier reset.

Tool Definition Quality

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context that the tool is stable, read-only, and provides details about the response fields including special values like -1 for runway when no consumption. No contradictions.

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?

The description is well-structured with clear sections (STATUS, description, USE WHEN, DO NOT USE WHEN, RESPONSE SHAPE). Every sentence is useful and no fluff.

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?

The description covers all necessary information for an agent to decide when to use this tool and interpret its results. It explains the response shape in detail, including special values. The presence of the output schema further supports completeness.

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?

The tool has zero parameters; per the guidelines, baseline is 4. The description does not need to add parameter meaning since there are none.

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 clearly states the tool reads the user's Talonic credit balance and related financial metrics. It uses specific verbs and nouns (read the user's current Talonic credit balance) and distinguishes from siblings by noting that per-call cost is in talonic_extract response.

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?

The description explicitly lists when to use (before large batches, when user asks about balance or budget) and when not to use (for per-call cost, for top-up). It provides alternatives: talonic_extract for single extraction cost, dashboard for top-up.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/talonicdev/talonic-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server