Corpus Law

Check account status

account.status

Check the credit balance, tier, rate limits, and upgrade options for the API key on this connection. Use it to budget before making metered calls. Free — this call does not consume a credit. Works without a key (anonymous callers get their free-tier numbers and the key URL); with a key it reports that key's balance and limits. It also returns a referral code: pass referral_code back on later calls to keep the same referral identity.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`referral_code`	No	An active referral code returned by an earlier account.status call. Pass it back to keep the same referral identity; if it is no longer active, account.status issues a new code instead.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`text`	Yes	Human-readable tool result (also mirrored in content[].text).
`isError`	No	True when the tool could not complete successfully.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 25, 2026

addedInput schema / properties / referral_code

Added value: +{
+  "description": "An active referral code returned by an earlier account.status call. Pass it back to keep the same referral identity; if it is no longer active, account.status issues a new code instead.",
+  "type": "string"
+}

First observedAug 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds significant behavior beyond the annotations: this call is free and does not consume a credit, it works without a key and returns free-tier numbers plus a key URL, and it reports the keyed balance/limits when a key is present. It also discloses the referral-code reuse behavior, giving an agent important side-effect context for later calls.

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?

Every sentence packs useful information: purpose, budgeting context, zero-cost behavior, key/anonymous behavior, and referral-code usage. The first sentence leads, and the rest remains eminently readable for a tool description. There is no fluff or redundancy.

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 tool has only one optional parameter and an existing output schema, so no return-value inventory is needed. The description already covers call semantics, billing impact, credential modes, and referral-code carryover, making the agent fully equipped to decide when to use it and how to call it.

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?

The single parameter is already fully documented by the input schema, including the meaning of an inactive referral_code. The tool description roughly repeats 'pass referral_code back to keep the same referral identity,' but does not add new semantic information beyond what the schema already provides. Baseline of 3 is appropriate.

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, concrete purpose — 'Check the credit balance, tier, rate limits, and upgrade options' — and uniquely identifies the API key as the resource being inspected. This clearly separates it from the formation/law siblings, none of which deal with account metering.

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?

The description explicitly states when to use the call: 'Use it to budget before making metered calls.' It also gives practical context around anonymous callers versus keyed callers. It does not list exclusions, but no competing sibling yields a clear alternative path for this use case.

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

All Corpus Law tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?