Skip to main content
Glama

Update Discount

discount_update

Edits a Plan Builder discount; only the fields sent change. discount_id is its uuid, handle or code, as for discount_get. Deactivate it with status: inactive: it stops applying to new subscriptions, and the ones that already got it keep it. A write that leaves an AUTOMATIC discount active REQUIRES confirm: true, unless it only changes name or description. Takes the app_id returned by apps_list. Returns the same shape as discount_get.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "app_id": "<app_id>",
      "discount_id": "<discount_id>"
    },
    "name": "discount_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeNoThe code merchants type, stored uppercase and unique per app. Required unless `auto_apply` is true; an automatic discount has no code.
nameNoInternal name of the discount.
typeNo`percentage` off the plan price, or a `fixed_amount` in USD.
valueNoThe percentage (0.01 to 100) or the USD amount (min 0.01).
app_idYesThe app uuid returned by `apps_list`.
statusNo`active` applies it from now on; `inactive` keeps it off. Deactivate a discount with `inactive`.
confirmNoMust be `true` when the write leaves an automatic discount active (anything beyond its name or description). Ignored otherwise.
durationNo`forever`, or `limited` to a number of billing cycles.
plan_idsNoPlan uuids (`plan_id` from `plans_list`) the discount is restricted to. Empty or omitted: every plan.
auto_applyNoTrue for an automatic discount: applied to every matching new subscription without a code. Writing an active automatic discount requires `confirm: true`.
descriptionNoOptional description.
discount_idYesDiscount uuid, handle or code from `discounts_list`.
availabilityNo`all` stores, or `specific` stores listed in `specific_shop_domains`.
max_redemptionsNoHow many subscriptions may use it in total (min 1). Null: no limit.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.
specific_shop_domainsNoThe *.myshopify.com domains allowed when `availability` is `specific`.
duration_interval_countNoBilling cycles the discount lasts. Required when `duration` is `limited`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive, closed-world write. The description adds real value beyond that: deactivating stops applying to new subscriptions while existing ones keep it, the confirm gate on automatic discounts, and that the response matches discount_get. That is useful mutation context, though it omits reversibility of other field edits and any rate-limit or permission notes.

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

Conciseness5/5

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

Front-loaded one-line purpose, then compact sentences each carrying a distinct fact (id forms, deactivation effect, confirm rule, app_id source, return shape). No filler, and the conditional confirm rule is stated precisely enough to act on.

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?

For a 17-parameter mutation tool with no output schema, the description covers required inputs, the id formats, the conditional confirm gate, and the return shape by reference to discount_get. Nothing essential for a correct call is missing.

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?

Schema coverage is already 100%, so the schema carries most parameter meaning, but the description adds cross-field logic the schema states only in fragments: discount_id accepts uuid/handle/code as in discount_get, and the confirm requirement is conditioned on status plus auto_apply rather than a single field. That interaction meaning is a genuine supplement.

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?

States a specific verb and resource plus the key write semantics: 'Edits a Plan Builder discount; only the fields sent change.' The partial-update behavior and the deactivation path make it distinguishable from discount_create and discounts_list without opening any schema.

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?

Gives concrete when-to guidance: use `status: inactive` to deactivate, supply `confirm: true` for writes that leave an automatic discount active (except name/description), and pull `app_id` from `apps_list`. It does not explicitly route to sibling tools for creating or reading discounts, so it stops short of full alternatives coverage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources