Skip to main content
Glama
PaddleHQ

Paddle MCP Server

Official
by PaddleHQ

preview_subscription_update

Preview subscription changes before applying them to verify proration, billing adjustments, and transaction outcomes without committing updates.

Instructions

This tool will preview an update for a subscription without applying those changes.

It's best practice to preview every time before updating the subscription to confirm the changes are as expected, especially when making updates to items, billing periods, and anything affecting proration.

The updateSummary object contains details of prorated credits and charges created, along with the overall result of the update.

If successful, the response includes immediateTransaction, nextTransaction, and recurringTransactionDetails to see expected transactions for the changes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subscriptionIdYesPaddle ID of the subscription.
customerIdNoUnique Paddle ID for this customer entity, prefixed with `ctm_`.
addressIdNoUnique Paddle ID for this address entity, prefixed with `add_`.
businessIdNoPaddle ID of the business that this subscription is for, prefixed with `biz_`. Include to change the business for a subscription.
currencyCodeNoSupported three-letter ISO 4217 currency code.
nextBilledAtNoRFC 3339 datetime string.
discountNoDetails of the discount applied to this subscription. Include to add a discount to a subscription. `null` to remove a discount.
collectionModeNoHow payment is collected for transactions created for this subscription. `automatic` for checkout, `manual` for invoices.
billingDetailsNoDetails for invoicing. Required if `collectionMode` is `manual`. `null` if changing `collectionMode` to `automatic`.
scheduledChangeNoSet to `null` to remove a scheduled change applied to a subscription. Pause the subscription, cancel the subscription, and resume the subscription to create scheduled changes instead.
itemsNoList of items on this subscription. Only recurring items may be added. Send the complete list of items that should be on this subscription, including existing items to retain.
customDataNoAny structured custom key-value data needed outside of Paddle's standard fields. Occasionally used by third-parties.
prorationBillingModeNoHow Paddle should handle proration calculation for changes made to a subscription or its items. Required when making changes that impact billing. For automatically-collected subscriptions, responses may take longer than usual if a proration billing mode that collects for payment immediately is used.
onPaymentFailureNoHow Paddle should handle changes made to a subscription or its items if the payment fails during update. If omitted, defaults to `prevent_change`.

Implementation Reference

  • The handler function that implements the core logic of the 'preview_subscription_update' tool by calling paddle.subscriptions.previewUpdate.
    export const previewSubscriptionUpdate = async (
      paddle: Paddle,
      params: z.infer<typeof Parameters.previewSubscriptionUpdateParameters>,
    ) => {
      try {
        const { subscriptionId, ...updateData } = params;
        const subscription = await paddle.subscriptions.previewUpdate(subscriptionId, updateData);
        return subscription;
      } catch (error) {
        return error;
      }
    };
  • src/tools.ts:602-612 (registration)
    Primary MCP tool registration entry, defining method name, description, input schema reference, and required permissions.
      method: "preview_subscription_update",
      name: "Preview an update to a subscription",
      description: prompts.previewSubscriptionUpdatePrompt,
      parameters: params.previewSubscriptionUpdateParameters,
      actions: {
        subscriptions: {
          write: true,
          preview: true,
        },
      },
    },
  • src/api.ts:82-82 (registration)
    API-level registration mapping the tool method constant to the handler function.
    [TOOL_METHODS.PREVIEW_SUBSCRIPTION_UPDATE]: funcs.previewSubscriptionUpdate,
  • Type reference to the Zod schema for input parameters (defined in parameters.js).
    params: z.infer<typeof Parameters.previewSubscriptionUpdateParameters>,
  • Constant defining the tool method string identifier.
    PREVIEW_SUBSCRIPTION_UPDATE: "preview_subscription_update",
Behavior3/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, suggesting this is a non-destructive operation that may involve writes (e.g., generating preview data). The description adds value by clarifying that changes are not applied ('without applying those changes') and detailing the response structure (e.g., updateSummary, transaction details). However, it doesn't disclose behavioral traits like rate limits, authentication needs, or error handling, which are not covered by annotations.

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, starting with the core purpose. Each sentence adds value: the first states the action, the second provides usage guidance, and the last two explain response details. There's no wasted text, but it could be slightly more structured (e.g., bullet points for response fields) without losing conciseness.

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 tool's complexity (14 parameters, nested objects) and lack of output schema, the description does well by explaining key response components (updateSummary, transaction details). However, it doesn't cover all contextual aspects like error cases, prerequisites (e.g., required permissions), or how it integrates with sibling tools (e.g., 'update_subscription' not listed). With annotations providing safety hints, it's mostly complete but has minor gaps.

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 input schema has 100% description coverage, thoroughly documenting all 14 parameters. The description adds minimal parameter semantics beyond the schema, only implying that parameters relate to subscription updates (e.g., 'items, billing periods, and anything affecting proration'). With high schema coverage, the baseline is 3, as the description doesn't significantly enhance parameter understanding.

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 clearly states the tool's purpose: 'preview an update for a subscription without applying those changes.' It specifies the verb ('preview') and resource ('subscription update'), distinguishing it from tools like 'update_subscription' (though not listed as a sibling). However, it doesn't explicitly differentiate from sibling tools like 'preview_subscription_charge' or 'preview_prices', which are also preview tools in the same domain, leaving some ambiguity.

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 usage guidelines: 'It's best practice to preview every time before updating the subscription to confirm the changes are as expected, especially when making updates to items, billing periods, and anything affecting proration.' This clearly indicates when to use this tool (before applying updates) and highlights critical scenarios, though it doesn't name specific alternative tools like 'update_subscription' (not in siblings).

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