Skip to main content
Glama

Get credit balance

get_balance
Read-onlyIdempotent

Requires an approved AlertForge account connection. OAuth-aware clients should start AlertForge's secure authorization flow and ask the user only to sign in and approve. Setup: https://alertforge.ai/ai-agents#agent-setup. Get the caller's current AlertForge credit balance.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely non-redundant context – an approved account connection is required, and OAuth clients must run AlertForge's authorization flow with a specific setup URL. It doesn't say what the balance looks like (units, currency, or whether low balance affects subsequent calls).

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?

Three sentences, none wasteful in isolation, but the ordering is backwards – the agent must read past account-setup boilerplate to learn what the tool does. Front-loading "Get the caller's current credit balance" would cost nothing and improve selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read with no output schema, the description covers the only real hazard: authorization state. It stops short of describing the returned value, which matters here because an agent likely needs the balance to decide whether to proceed with a paid generation call.

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 takes zero parameters, so under the rubric the baseline is 4. The description correctly adds no parameter discussion, instead spending its words on the auth prerequisite, which is the only real precondition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The final sentence states a specific verb and resource: "Get the caller's current AlertForge credit balance." That is unambiguous and distinguishable from the sibling tools, which are all generation/planning/status operations. It loses a point only because the purpose sentence is buried after the auth boilerplate rather than front-loaded.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is only implied: an agent can infer you'd check credits before kicking off expensive pack/render jobs, but the description never says so, nor does it state any condition or alternative. The setup instructions are prerequisite guidance rather than when-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.