Skip to main content
Glama

Create or Update Plan

apply_plan
Idempotent

Set up or reshape ONE subscription plan in a single call: its name, description, trial, prices, features and quotas together. Creates the plan when the key is new and updates it when it exists, in one write, so a plan is never left half-configured. A new plan needs name, at least one price and, when it charges, trial (true or false); a price above 0 needs currency unless the plan's prices already use exactly one. These are the developer's decisions: when one is missing the tool changes nothing and returns DECISION_NEEDED listing the questions to ask. prices ([{ amount, interval, currency? }]) are upserted by currency + interval and quotas ([{ metric, limit, policy, kind?, source?, priceAmount?, priceCurrency? }]) by metric, with the same rules as set_plan_price and set_plan_quota; features ([{ key, name? }], the on/off features the plan includes) are upserted by key; removePrices ([{ interval, currency? }]), removeQuotas ([metric]) and removeFeatures ([key]) remove the named ones. Anything the call does not mention is kept. Returns the full plan. The CLI's bridge plan apply --spec takes the same JSON. Call list_plan_quotas without a planKey first to reuse the metric names the app already has instead of inventing new ones. Seats: name the limit (e.g. seats), kind gauge, source membership; Bridge counts the workspace's active members, pending invites included. Enforce it where invites happen: the built-in team page with its seat-limit setting, or @RequireQuota on the app's own invite handler. Never a flag or an entitlement. Count usage once, where the action happens: ask the developer whether the action calls their server. If it does, the backend decorator (@RequireQuota) counts it. If it does not, the browser reports it (bridge.usage.report / set) with on the button; that is a complete, first-class setup. Never count one metric in both places. Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoId of the Bridge app to act on for this call (see list_apps). Omit to use the current app.
keyYesPlan KEY. A new key creates the plan; an existing one reshapes it.
nameNoDisplay name. Required when the plan is new.
trialNoWhether the plan has a trial period. false removes one.
pricesNoPrices to add or replace, one per currency + interval. A new plan needs at least one.
quotasNoQuotas to add or replace, one per metric. kind: counter (default) or gauge. If deleting it frees room, it's a gauge and your app counts it; if it happened, it's a counter and Bridge counts it. source: "membership" on a hard gauge makes Bridge count the workspace's active members (seats).
featuresNoOn/off features the plan includes, added or renamed by key. A plan feature is an on/off feature the plan sells; gate it with a feature flag whose rule is `bridge:billing.entitlement.<featureKey>` eq true, so the flag follows the plan's feature list and never names plans.
trialDaysNoTrial length in days. Required when trial is true.
descriptionNoShort description shown with the plan.
removePricesNoPrices to remove, by interval + currency (default: the plan's one currency).
removeQuotasNoMetric keys whose quotas to remove.
removeFeaturesNoFeature keys to remove from the plan.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / quotas / items / properties / source / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedInput schema / properties / removePrices / items / properties / interval / $ref
      Removed value: -"#/properties/prices/items/properties/interval"
    • addedInput schema / properties / removePrices / items / properties / interval / description
      Added value: +"Billing recurrence interval."
    • addedInput schema / properties / removePrices / items / properties / interval / enum
      Added value: +[
      +  "day",
      +  "week",
      +  "month",
      +  "year"
      +]
    • addedInput schema / properties / removePrices / items / properties / interval / type
      Added value: +"string"
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations it discloses real behavioral traits: DECISION_NEEDED is returned with the questions to ask when a developer decision is missing, 'anything the call does not mention is kept', and 'Returns the full plan'. The atomic 'never left half-configured' framing and the upsert-by-key rules (currency+interval, metric, key) are not derivable from the annotations. Note the tension with destructiveHint=false given the explicit remove* operations, but these are caller-named, reversible config removals rather than a true contradiction.

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 core purpose and upsert/removal rules are front-loaded in the first few sentences, but the description then drifts into broad integration guidance (seat quotas, @RequireQuota vs browser reporting, QuotaGate) that is tangential to invoking this tool. Information-dense rather than padded, but substantially oversized for a tool definition.

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 12-parameter mutation tool with no output schema, it covers what an agent needs: return value ('the full plan'), the DECISION_NEEDED failure mode, merge semantics for unmentioned fields, and per-collection upsert keys. Annotations cover safety/idempotency and the schema covers field detail, so nothing essential is missing.

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?

Schema description coverage is 100% and the schema itself is already rich, documenting currency rules, interval enums, quota kind/source and feature key patterns. The description adds the upsert-by-key grouping and the 'same rules as set_plan_price/set_plan_quota' cross-reference, but mostly restates what the schema already carries, so the baseline 3 applies.

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 opening sentence states a specific verb and resource ('Set up or reshape ONE subscription plan in a single call') and immediately defines the upsert scope: creates on a new key, updates on an existing one. It is clearly differentiated from the many siblings that do a single piece (set_plan_price, set_plan_quota, add_plan_feature, create_plan/update_plan) by being the one-call composite.

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?

It gives explicit when-to-use and prerequisite guidance: call list_plan_quotas without a planKey first to reuse existing metric names, and call get_integration_guide with topic=billing before writing consuming app code. It also names the CLI equivalent and routes callers to set_plan_price/set_plan_quota semantics for the nested rules.

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.