Skip to main content
Glama
PaddleHQ

Paddle MCP Server

Official
by PaddleHQ

create_adjustment

Create refunds or credits for billed transactions by specifying transaction details, adjustment type, and tax calculation method to record revenue-impacting actions after billing.

Instructions

This tool will create an adjustment to refund or credit all or part of a transaction and its items.

Billed transactions are considered financial records for tax and legal purposes, so they can't be changed. Adjustments record actions that impact revenue for a transaction after it's been billed.

Don't use this tool without checking with the user first. Avoid using before gaining explicit approval.

The transaction ID and the IDs of any transaction items (details.lineItems[].id) are required to create a refund or credit.

An adjustment can have an action of credit or refund:

  • Refunds return an amount to a customer's original payment method. Create refund adjustments for transactions that are completed.

  • Credits reduce the amount that a customer has to pay for a transaction. Create credit adjustments for manually-collected transactions that are billed or past_due.

Most refunds for live accounts are created with the status of pending_approval until reviewed by Paddle, but some are automatically approved. For sandbox accounts, Paddle automatically approves refunds every ten minutes.

Other action types (chargeback, chargeback_reverse, chargeback_warning, chargeback_warning_reverse, credit_reverse) are automatically created by Paddle and can't be set manually.

Adjustments can apply to some or all items on a transaction by defining the type:

  • full: The grand total for the related transaction is adjusted.

  • partial: Some line items for the related transaction are adjusted. Requires items.

When selecting taxMode, choose the one that best describes how the tax should be calculated for the adjustment:

  • external: Amounts are exclusive of tax. Common in European countries.

  • internal: Amounts are inclusive of tax. Common in countries like the United States and Canada.

Creating an adjustment for a transaction that has a refund that's pending approval isn't possible.

Ensure you have all the information needed before making the call. Don't fabricate, imagine, or infer details and parameter values unless explicitly asked to. If anything is ambiguous, unknown, or unclear, ask the user for clarification or details before you proceed.

If successful, the response includes a copy of the new adjustment entity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesHow this adjustment impacts the related transaction.
typeNoType of adjustment. Use `full` to adjust the grand total for the related transaction. Include an `items` array when creating a `partial` adjustment. If omitted, defaults to `partial`.
taxModeNoWhether the amounts to be adjusted are inclusive or exclusive of tax. If `internal`, adjusted amounts are considered to be inclusive of tax. If `external`, Paddle calculates the tax and adds it to the amounts provided. Only valid for adjustments where the `type` is `partial`. If omitted, defaults to `internal`.
transactionIdYesPaddle ID of the transaction that this adjustment is for, prefixed with `txn_`. Automatically-collected transactions must be `completed`, and manually-collected transactions must be `billed` or `past_due`.
reasonYesWhy this adjustment was created. Appears in the Paddle dashboard. Retained for record-keeping purposes.
itemsYesList of transaction items to adjust. Required if `type` is not populated or set to `partial`.

Implementation Reference

  • The handler function that implements the core logic of the 'create_adjustment' tool by calling Paddle's adjustments.create API.
    export const createAdjustment = async (
      paddle: Paddle,
      params: z.infer<typeof Parameters.createAdjustmentParameters>,
    ) => {
      try {
        const adjustment = await paddle.adjustments.create(params);
        return adjustment;
      } catch (error) {
        return error;
      }
    };
  • The tool schema defining the input parameters (Zod schema), description, name, method, and required permissions/actions for the create_adjustment tool.
    {
      method: "create_adjustment",
      name: "Create an adjustment",
      description: prompts.createAdjustmentPrompt,
      parameters: params.createAdjustmentParameters,
      actions: {
        adjustments: {
          write: true,
          create: true,
        },
      },
    },
  • src/api.ts:26-26 (registration)
    Registration of the createAdjustment handler function in the toolMap dictionary used by the PaddleAPI class to map tool method names to their implementations.
    [TOOL_METHODS.CREATE_ADJUSTMENT]: funcs.createAdjustment,
  • Constant defining the string identifier for the CREATE_ADJUSTMENT tool method, used in registration and schema.
    CREATE_ADJUSTMENT: "create_adjustment",
Behavior4/5

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

The description adds valuable behavioral context beyond the annotations. While annotations indicate it's not read-only and not destructive, the description explains: 'Billed transactions are considered financial records for tax and legal purposes, so they can't be changed. Adjustments record actions that impact revenue for a transaction after it's been billed.' It also details approval workflows: 'Most refunds for live accounts are created with the status of pending_approval until reviewed by Paddle, but some are automatically approved. For sandbox accounts, Paddle automatically approves refunds every ten minutes.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is comprehensive but somewhat verbose at 18 sentences. While most content is valuable, some sections could be more concise (e.g., the repeated warnings about checking with users). The structure is logical but not optimally front-loaded, with usage guidelines appearing after technical explanations rather than immediately after the purpose statement.

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?

Given the complexity of financial adjustments and the absence of an output schema, the description provides substantial context about the tool's behavior, constraints, and business logic. It explains the distinction between refunds and credits, approval workflows, tax modes, and transaction state requirements. However, it could provide more detail about the response structure since there's no 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 baseline is 3. The description adds some semantic context about parameters (e.g., explaining when to use 'refund' vs 'credit', 'full' vs 'partial' adjustments, and 'external' vs 'internal' tax modes), but most parameter details are already well-covered in the schema descriptions. The description doesn't add significant new parameter information beyond what the schema provides.

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 tool's purpose: 'create an adjustment to refund or credit all or part of a transaction and its items.' It distinguishes this from sibling tools like 'create_transaction' by focusing specifically on post-billing adjustments rather than initial transactions, and explains why adjustments are needed (billed transactions can't be changed).

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 provides explicit guidance on when to use this tool vs alternatives: 'Don't use this tool without checking with the user first. Avoid using before gaining explicit approval.' It also specifies prerequisites: 'Ensure you have all the information needed before making the call' and warns against creating adjustments when 'a transaction that has a refund that's pending approval.'

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