spriteship

Get credit balance

get_credits

Read-onlyIdempotent

Current credit balance, and optionally the recent ledger. Every ledger entry carries apiKeyId/apiKeyName so you can see exactly what THIS key spent. Check the balance before proposing any paid generation. When the balance will not cover what the user wants, say what IS affordable rather than only that they are short — "1200 for all three animations, you have 900, so two now or top up for all three" is the useful answer. Two different walls exist and they need OPPOSITE advice: running out of BALANCE is fixed by buying credits (the 402 carries a topUpUrl — send that link, never quote prices, they change), while a free account may instead have wallet balance but no rolling allowance — get_credits reports its freeCreditLimit. If needed <= limit, wait for the non-null resetsAt; if needed > limit, resetsAt is null because waiting can never make that unchanged request fit. Report that and never reduce or split work without fresh user approval. freeCreditLimit.firstAnimationAllowance reports whether the one activation exception is still available: exactly one fresh playable character animation plus required setup, at most 1000 credits, before two recent net-paid generation jobs and before any successful playable animation. Explicit turn/turn_* rotations, reuse, edit, mirror, and multi-animation requests do not qualify; a failed fully-refunded claim is reusable only if no playable animation was produced. Never split or reshape work to manufacture eligibility. An eligible reset, or completing any plan/pack purchase, clears that wall. hitting the key's DAILY SPEND CAP is not a money problem at all — the credits are already in the account, and the fixes are raising the cap or waiting for resetsAt. Never suggest a purchase for a cap trip. If the user asks HOW to raise the cap: the 403 carries capSettingsUrl — give them that link and tell them to edit the key there. YOU cannot change it, by design: the cap edit needs a logged-in session and is unreachable with an API key, because a key that could raise its own cap would not be a cap. Do not retry hoping it passes, and do not ask them to paste credentials.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max items to return (default 100, max 500).
`apiKeyId`	No	Filter ledger entries to one key (UUID).
`includeLedger`	No	Also return recent ledger entries.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds substantial behavioral context: resetsAt null/non-null semantics, firstAnimationAllowance eligibility rules, the 402/403 URL behaviors, and why the cap cannot be raised via API. No contradictions with annotations exist.

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 description is front-loaded with the core function and every subsequent sentence addresses a distinct operational decision. It is unusually long, but the length is justified by the tool's nuanced advisory role. Minor lack of structural formatting (e.g., bullets for the different walls) keeps it from a 5.

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 tells the agent everything needed to call the tool and interpret results correctly: what fields are reported, what resetsAt means, how freeCreditLimit works, how to handle 402/403 responses, and how to advise users. Nothing critical for correct invocation or response interpretation is missing.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds some contextual color—notably that ledger entries identify the consuming key and that includeLedger is optional—but it does not materially deepen the meaning of limit or apiKeyId beyond the schema's own descriptions. This meets, but does not clearly exceed, the baseline.

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 first line, 'Current credit balance, and optionally the recent ledger,' clearly identifies the tool's verb-resource relationship and scope. It is the only sibling focused on credits/balance, so it is naturally distinguished from all other listed tools. The follow-up about ledger entries with apiKeyId/apiKeyName reinforces a unique purpose.

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 is explicit about when to use the tool: 'Check the balance before proposing any paid generation.' It also provides detailed conditional guidance for three distinct situations—balance shortfall, freeCreditLimit wall, and daily spend cap—and explicitly says what not to do ('Never suggest a purchase for a cap trip'). This is far beyond vague usage hints.

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

All spriteship 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.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, and the descriptions are extremely detailed with cross-references (e.g., animate_asset vs frame_animation vs generate_character_animation). A few pairs like reprocess_asset vs revise_asset could be confused initially, but their descriptions and use cases are explicit enough to prevent misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_project, get_asset, cancel_job). Verbs are imperative and nouns are appropriately singular/plural, making the API predictable and readable.

Tool Count2/5

At 41 tools, the server is far beyond the 15-25 range considered reasonable for most APIs. While the domain is broad (project, assets, characters, animations, jobs, exports, credits), the sheer number creates a heavy surface that may overwhelm agents and suggests the API could be consolidated into higher-level operations.

Completeness4/5

The tool set covers the full creative pipeline: project creation, asset/character generation, animation (both AI and frame-based), revisions, exports, and job management. Minor gaps include lack of delete operations for assets/characters/projects and no listing of all jobs, but these are not critical for the core workflow and are likely intentional for a generative art platform.

Resources

Need Help?