Skip to main content
Glama
PaddleHQ

Paddle MCP Server

Official
by PaddleHQ

create_simulation

Create test webhook simulations for Paddle notification settings to validate webhook implementations before sending real events, supporting single events or subscription scenarios.

Instructions

This tool will create a new simulation for a notification setting (notification destination) in Paddle.

Test webhooks can be sent through the webhook simulator in the dashboard or via the API by creating and running a simulation. Simulations configure which test webhooks are sent by Paddle when run. They can simulate the sending of single events or scenarios which send multiple events, like subscription renewals or cancellations. This is ideal for testing webhook implementations and validating data before sending real events. If implementing webhooks or making changes to an implementation, create and run a simulation prior to sending real events.

For scenario simulations (type of subscription_creation, subscription_renewal, subscription_pause, subscription_resume, subscription_cancellation), config objects can be provided. The config object contains a key matching the scenario type (e.g., for type "subscription_creation", use config.subscription_creation). This nested object can contain entities and options fields to control which webhooks are sent and populate payloads with real entity data. If provided, the config object must match the scenario type selected.

Option values for scenario simulations:

subscriptionCancellation and subscriptionPause:

  • options.effectiveFrom:

    • next_billing_period: Simulates as if the subscription cancels or pauses at the start of next billing period.

    • immediately: Simulates as if the subscription cancels or pauses immediately.

subscriptionResume and subscriptionRenewal:

  • options.paymentOutcome:

    • success: Simulates as if the payment for the subscription is successful.

    • recovered_existing_payment_method: Simulates as if the payment for the subscription fails initially and the payment is recovered when retrying the existing payment method.

    • recovered_updated_payment_method: Simulates as if the payment for the subscription fails initially and the customer updates their payment method to successfully pay.

    • failed: Simulates as if the payment for the subscription is unsuccessful after all payment recovery attempts are exhausted.

  • options.dunningExhaustedAction (only valid when paymentOutcome is "failed"):

    • subscription_paused: Simulates as if the subscription is paused after all payment recovery attempts are exhausted.

    • subscription_canceled: Simulates as if the subscription is canceled after all payment recovery attempts are exhausted.

subscriptionCreation:

  • options.customerSimulatedAs:

    • new: Simulates as if a new customer enters their details at checkout and Paddle creates a new customer.

    • existing_email_matched: Simulates as if an existing customer enters their details at checkout. Paddle matches it to an existing customer based on the email supplied and creates a new address for that customer.

    • existing_details_prefilled: Simulates as if existing customer details are prefilled at checkout by passing them to Paddle.js.

  • options.businessSimulatedAs:

    • not_provided: Simulates as if no business is provided.

    • new: Simulates as if a customer enters their business details at checkout and Paddle creates a new business.

    • existing_details_prefilled: Simulates as if an existing business is prefilled at checkout by passing it to Paddle.js.

  • options.discountSimulatedAs:

    • not_provided: Simulates as if no discount is entered.

    • prefilled: Simulates as if a discount is prefilled at checkout by passing it to Paddle.js. Requires entities.discountId.

    • entered_by_customer: Simulates as if a customer entered a discount at checkout. Requires entities.discountId.

If config.entities are not provided, simulated webhook payloads are populated with static demo examples.

If successful, the response includes a copy of the new simulation entity. The simulation can then be run to send the events to the notification destination with the create_simulation_run tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notificationSettingIdYesPaddle ID of the notification setting (destination) where this simulation is sent, prefixed with `ntfset_`.
nameYesName of this simulation to identify internally.
typeYesType of event sent by Paddle, in the format `entity.event_type`. Either single events (e.g. 'subscription.created') or scenarios for multiple events (e.g. 'subscription_creation').
payloadNoSimulation payload. Pass a JSON object that matches the schema for an event type to simulate a custom payload. If omitted, Paddle populates with a demo example. Only for single event simulations, not scenarios.
configNoConfiguration for this scenario simulation. Determines which granular flow is simulated and what entities are used to populate webhook payloads with.

Implementation Reference

  • The main handler function that implements the logic for the 'create_simulation' tool. It takes a Paddle instance and parameters, then calls paddle.simulations.create to create the simulation.
    export const createSimulation = async (
      paddle: Paddle,
      params: z.infer<typeof Parameters.createSimulationParameters>,
    ) => {
      try {
        // eslint-disable-next-line @typescript-eslint/no-explicit-any
        const simulation = await paddle.simulations.create(params as any);
        return simulation;
      } catch (error) {
        return error;
      }
    };
  • src/api.ts:56-56 (registration)
    Registers the 'create_simulation' tool method to its handler function in the toolMap used by PaddleAPI to dispatch calls.
    [TOOL_METHODS.CREATE_SIMULATION]: funcs.createSimulation,
  • Defines the tool specification including method name, description, input parameters schema reference (params.createSimulationParameters), and required actions for the 'create_simulation' tool.
      method: "create_simulation",
      name: "Create a simulation",
      description: prompts.createSimulationPrompt,
      parameters: params.createSimulationParameters,
      actions: {
        simulations: {
          write: true,
          create: true,
        },
      },
    },
  • src/constants.ts:48-48 (registration)
    Defines the constant string identifier for the 'create_simulation' tool method used across the codebase.
    CREATE_SIMULATION: "create_simulation",
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 that simulations are for testing webhooks, populate payloads with demo examples if config.entities are not provided, and the response includes a copy of the new simulation entity. It also mentions the tool's purpose in validation before real events, which provides important usage context.

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 appropriately front-loaded with core purpose and usage, but becomes verbose with extensive option value explanations that might be better placed in parameter-specific documentation. While all content is relevant, the length could challenge quick comprehension, though it maintains a logical flow from general to specific details.

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 (5 parameters, nested objects, no output schema), the description provides substantial context. It explains the tool's role in the testing workflow, distinguishes between event types, details configuration options, and mentions the response format. The main gap is lack of explicit error handling or permission requirements, but overall it's quite comprehensive for this complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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, but the description adds significant semantic value. It explains the distinction between single events and scenarios, provides detailed option values for scenario simulations (e.g., paymentOutcome meanings), clarifies config object requirements, and explains what happens when config.entities are omitted. This goes well beyond the schema's technical documentation.

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 creates a new simulation for a notification setting in Paddle, specifying it configures test webhooks for single events or scenarios. It distinguishes from sibling tools like 'create_simulation_run' by explaining this tool creates the simulation while the sibling runs it, and from other 'create_' tools by focusing on webhook testing rather than actual resource creation.

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 explicitly states when to use this tool: 'ideal for testing webhook implementations and validating data before sending real events' and 'create and run a simulation prior to sending real events.' It also provides clear alternatives by mentioning the webhook simulator in the dashboard and specifying that the 'create_simulation_run' tool is used after creation to send events.

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