Skip to main content
Glama
PaddleHQ

Paddle MCP Server

Official
by PaddleHQ

list_credit_balances

Read-only

Retrieve customer credit balances across currencies to view available, reserved, and used amounts for transaction-based credits in Paddle Billing.

Instructions

This tool will list credit balances in each currency for a customer.

Credit balances are created automatically by Paddle when a customer takes an action that results in Paddle creating a credit for a customer, like making prorated changes to a subscription. These are transaction credits, not promotional credits like from discounts.

Each balance has three totals:

  • available: Total available to use.

  • reserved: Total temporarily reserved for billed transactions.

  • used: Total amount of credit used.

Credit is added to the available total initially. When used, it moves to the used total.

The reserved total is used when a credit balance is applied to a transaction that's marked as billed, like when working with an issued invoice. It's not available for other transactions at this point, but isn't considered used until the transaction is completed. If a billed transaction is canceled, any reserved credit moves back to available.

A credit balance can only be used for transactions in the same currency.

Adding to a credit balance directly isn't possible. Create a credit adjustment with the create_adjustment tool to reduce the amount due to pay for a transaction instead.

Filter credit balances by currencyCode as needed. Amounts are in the smallest currency unit (e.g., cents).

The response isn't paginated. An empty array is returned if a customer has no credit balances.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
customerIdYesPaddle ID of the customer.
currencyCodeNoReturn entities that match the currency code. Use a comma-separated list to specify multiple currency codes.

Implementation Reference

  • The handler function that executes the core logic of the list_credit_balances tool by calling the Paddle SDK's customers.getCreditBalance method.
    export const listCreditBalances = async (
      paddle: Paddle,
      params: z.infer<typeof Parameters.listCreditBalancesParameters>,
    ) => {
      try {
        const { customerId, ...queryParams } = params;
        const result = await paddle.customers.getCreditBalance(customerId, queryParams);
        return result;
      } catch (error) {
        return error;
      }
    };
  • The tool schema definition, including method name, description, Zod parameters schema reference, and required permissions/actions.
    {
      method: "list_credit_balances",
      name: "List credit balances for a customer",
      description: prompts.listCreditBalancesPrompt,
      parameters: params.listCreditBalancesParameters,
      actions: {
        customers: {
          read: true,
          list: true,
        },
      },
    },
  • src/api.ts:28-28 (registration)
    Registration of the listCreditBalances handler in the central toolMap used by PaddleAPI to dispatch tool calls.
    [TOOL_METHODS.LIST_CREDIT_BALANCES]: funcs.listCreditBalances,
  • Constant definition for the tool method name string used across the codebase.
    LIST_CREDIT_BALANCES: "list_credit_balances",
Behavior4/5

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

The annotations provide readOnlyHint=true, but the description adds valuable behavioral context beyond this: it explains that credit balances are automatically created by Paddle for transaction credits (not promotional), describes the three balance totals (available, reserved, used) and their lifecycle, states that response isn't paginated, and clarifies that empty arrays are returned for no balances. This significantly enhances understanding of the tool's behavior.

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 appropriately sized and front-loaded with the core purpose. While comprehensive, some sentences could be more concise (e.g., the reserved total explanation is detailed but necessary). The structure flows logically from purpose to credit explanation to balance details to usage notes.

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?

Given the complexity of credit balances and the absence of an output schema, the description provides excellent contextual completeness. It thoroughly explains what credit balances are, how they're created, the three balance types and their relationships, currency restrictions, how to affect balances (via create_adjustment), filtering, amount format, and response behavior. This compensates well for the lack of output schema.

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?

With 100% schema description coverage, the schema already documents both parameters well. The description adds minimal parameter-specific information beyond the schema - it mentions filtering by currencyCode and that amounts are in smallest currency units, but doesn't provide additional semantic context about the customerId parameter or currencyCode usage beyond what's in the schema descriptions.

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 clearly states the specific action ('list credit balances in each currency for a customer'), identifies the resource ('credit balances'), and distinguishes it from sibling tools by focusing on credit balances rather than other entities like addresses, adjustments, or transactions. The opening sentence provides immediate clarity about the tool's function.

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 provides clear context about when to use this tool (to list credit balances created by Paddle for transaction credits) and explicitly mentions an alternative tool ('create_adjustment') for adding to credit balances. However, it doesn't explicitly state when NOT to use this tool versus other list_* siblings, though the credit balance focus is distinct enough.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PaddleHQ/paddle-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server