Skip to main content
Glama
Sign In
JANCTION Render

JANCTION Render

by JasmyLab-JANCTION
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

billing

Read-onlyIdempotent

Check remaining free GPU time, its expiry or reset, credit balance, price per GPU-second, active offers, and any pending checkout link. Set topup_yen to generate a Stripe top-up link.

Instructions

Check what this key can still render for free and its credit (no GPU time): the free GPU time left and when it expires or resets, the balance, the price per GPU-second, any pending checkout link, and the offers that apply. Relay tell_user to the user in their language when it is present.

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": "billing"
  }
}

Input Schema

NameRequiredDescriptionDefault
topup_yenNo0 = just report the quota / balance; > 0 = create a Stripe checkout link for that amount in yen (an amount below the minimum top-up is refused and the reply says the minimum).

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.205
    • changedInput schema / properties / topup_yen / description
      Previous value: -"0 = just report the quota / balance; > 0 (minimum 500) = create a Stripe checkout link for that amount in yen."New value: +"0 = just report the quota / balance; > 0 = create a Stripe checkout link for that amount in yen (an amount below the minimum top-up is refused and the reply says the minimum)."
  2. Changed1 schema field changedv0.4.119
    • addedInput schema / properties / topup_yen / description
      Added value: +"0 = just report the quota / balance; > 0 (minimum 500) = create a Stripe checkout link for that amount in yen."
  3. First observedv0.2.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety baseline is covered. The description adds useful context about no GPU time, returned billing fields, and relaying tell_user, but it does not mention that topup_yen > 0 creates a Stripe checkout link, so an optional side effect is left to the schema.

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 purpose and then lists the relevant returned categories, plus a necessary relay instruction. It is somewhat dense and partly repeats what the output schema can convey, but no sentence is clearly wasted.

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?

With an output schema present and full schema description coverage, the definition is largely complete for an agent. The main omission is that the description frames the tool as a check and does not surface the optional checkout-link creation behavior, though the parameter schema does document 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?

Schema description coverage is 100%, so topup_yen is already fully documented in the schema, including the 0 vs >0 behavior and minimum top-up refusal. The description adds no parameter-specific meaning beyond the schema, which is the expected baseline.

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 description gives a specific action and scope: checking what this key can still render for free, its credit, balance, price, checkout link, and offers. The 'no GPU time' framing helps distinguish it from the render_* siblings, though it does not explicitly name alternatives.

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 implied as a quota/credit check that does not consume GPU time, but there is no explicit when-to-use guidance or comparison to sibling tools such as render_estimate or render_info. It is adequate but leaves the agent to infer the workflow context.

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

Deploy Server

Other Tools