Skip to main content
Glama

The Bridge

by dev.thebridge
OverviewDiscussionsAdmin

Set Plan Quota

set_plan_quota
Idempotent

Add or update a per-metric usage quota on a plan (idempotent by metric: an existing quota for that metric is replaced, others kept). Before writing app code that consumes this, call get_integration_guide with topic=billing and the framework the app uses. 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. limit is the included units (0 = metered from unit 1); policy ("hard" blocks at the limit; "metered" bills each unit above it and needs priceAmount > 0 per unit and a currency — priceCurrency defaults to the plan's one price currency). Hard quotas must NOT carry priceAmount. A quota is for something counted. An on/off feature the plan sells (analytics, SSO, export) belongs in the plan's features, set with add_plan_feature — not a hard quota with limit 1. kind: "counter" (default) sums events per billing period and resets (API calls, emails sent); "gauge" is an absolute value the app sets, never reset (projects, tickets, storage). 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. A gauge cannot be metered. source "membership" (gauge only) makes Bridge count the workspace's active members; omitting source keeps an existing gauge's, null removes it. Omitting kind keeps an existing quota's kind. list_plan_quotas shows every metric name and its kind; remove_plan_quota deletes one.

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 (see list_plans).
kindNocounter (default) = summed per billing period; gauge = absolute value the app sets, never reset. 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.
limitYesIncluded units. 0 = pure per-unit metered (billed from unit 1).
metricYesMetric KEY the app reports usage against, e.g. "projects". Reuse the names list_plan_quotas shows.
policyYeshard blocks at the limit; metered keeps going and bills each unit above it.
sourceNomembership = Bridge counts the workspace's active members (pending invites included); the app never reports it. Gauge + hard only. Use it for seats. null removes it.
priceAmountNoPer-unit price for metered quotas (required with policy=metered).
priceCurrencyNoCurrency for the metered price (defaults to the plan's price currency when unambiguous).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / source / type
      Added value: +[
+  "string",
+  "null"
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (which cover readOnly/idempotent/destructive), the description discloses idempotency-by-metric behavior, that other quotas are kept, cross-field validation (hard quotas must NOT carry priceAmount; metered requires priceAmount > 0 and a currency), that metered is incompatible with gauge, and that omitting kind/source preserves existing values.

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?

Purpose is front-loaded, but the body is a dense, long multi-sentence block with some redundancy against the schema (counter/gauge rules restated) and slightly meandering asides ('A quota is for something counted'). It is information-rich but not tightly trimmed.

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 9-parameter mutation with no output schema, the description covers everything an agent needs: where/how usage is counted, seats handling, gauge vs counter edge cases, and pointers to related tools. Nothing material 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 100%, so the baseline is 3, but the description adds cross-parameter meaning not captured per-field: default currency resolution, priceAmount requirements per policy, and defaulting behavior for omitted kind/source. It largely reinforces the schema rather than adding entirely new per-param detail, so it sits just above baseline.

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 ('Add or update a per-metric usage quota on a plan') and immediately names the idempotency semantics. It explicitly distinguishes itself from sibling alternatives like add_plan_feature (on/off features), list_plan_quotas, and remove_plan_quota.

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 concrete when-to-use rules: hard vs metered policy, gauge vs counter selection, when to route to get_integration_guide first, and when an item belongs in add_plan_feature instead of a quota. Explicit alternatives and exclusions are provided throughout.

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

All The Bridge toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources