alterlab-mcp-server

Check Balance

alterlab_check_balance

Read-onlyIdempotent

Check AlterLab account balance, status, and credit usage before batch scrapes or large crawls to verify sufficient funds and avoid failed expensive operations.

Instructions

Check your AlterLab account balance, status, and credit usage. Call this before expensive operations (batch scrapes, large crawls) to verify sufficient funds. Returns current balance in dollars, balance status (healthy/low/critical/exhausted), total deposited, and total spent. For a full spending breakdown by time window and top domains, use alterlab_get_usage instead. No parameters required — uses your API key for identification.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "alterlab_check_balance"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.5.0Jun 12, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered structurally. The description adds real behavioral context beyond that: it enumerates the returned fields (balance in dollars, status tiers healthy/low/critical/exhausted, total deposited, total spent) and notes that identification happens via the API key rather than parameters. It does not mention rate limits or failure behavior, which keeps it below a 5.

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?

Four compact sentences, each doing distinct work: purpose, proactive usage trigger, return contract, and sibling routing. The action-oriented guidance is front-loaded and there is no filler.

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?

There is no output schema, so the description carries the burden of describing return values and does so concretely, including the status enum values. For a zero-parameter read tool this is as complete as an agent needs to call it correctly and interpret the result.

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?

With zero parameters the baseline is 4, and the description reinforces the schema by explaining that no arguments are needed and that identity comes from the API key. This is useful clarification of an implicit auth mechanism, though there are no parameters whose semantics could be expanded further.

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 opens with a specific verb+resource ("Check your AlterLab account balance, status, and credit usage") and immediately delineates itself from the sibling alterlab_get_usage by scope. An agent can distinguish it from the spending-breakdown tool without opening either schema.

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?

It gives an explicit trigger ("Call this before expensive operations (batch scrapes, large crawls) to verify sufficient funds") and names the alternative along with the condition that selects it ("For a full spending breakdown by time window and top domains, use alterlab_get_usage instead"). Both when-to-use and when-to-use-something-else are covered.

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