Skip to main content
Glama

create_checkout_session

Create a Stripe Checkout link that subscribes the workspace to a plan. Returns {url, sessionId}. Nothing is charged until a person opens the url and completes payment, so hand it to whoever owns the workspace. Every workspace gets 5,000 free credits a month (reset on the 1st) and can crawl on those without a plan; a plan adds a larger monthly allowance and storage. The caller must be an OWNER or ADMIN of the tenant. An agent-created workspace must be claimed by a person first: until then this returns 409 WORKSPACE_UNCLAIMED with the claimUrl to send them. Plan prices and monthly credits: GET /api/pricing (no token needed).

Input Schema

NameRequiredDescriptionDefault
tenantIdYesPath parameter tenantId.
priceTierYesPlan to subscribe to. studio is the smaller; agency carries more monthly credits and storage.
returnUrlNoWhere Stripe sends the person after checkout. Must be a page on the dashboard origin; defaults to the workspace's billing page. Leave it out unless you have a reason.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / priceTier / description
      Previous value: -"Plan to subscribe to. base is the cheapest; studio and agency carry more monthly credits and storage."New value: +"Plan to subscribe to. studio is the smaller; agency carries more monthly credits and storage."
    • changedInput schema / properties / priceTier / enum
      Previous value: -[
      -  "base",
      -  "studio",
      -  "agency"
      -]New value: +[
      +  "studio",
      +  "agency"
      +]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: nothing is charged until a person opens the URL, the specific 409 WORKSPACE_UNCLAIMED failure with a claimUrl, and where to check pricing. Auth requirement and no-charge semantics are stated.

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?

Front-loads the action and return value in the first two sentences, which is well structured. It is somewhat long, and the free-credits/pricing tangent could be trimmed, but each sentence still informs the calling decision.

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?

Even without an output schema, it describes the return shape ({url, sessionId}) and covers the key edge case (unclaimed workspace -> 409 + claimUrl) plus auth. Nothing an agent needs to invoke it correctly 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 decision value beyond the schema by contrasting what a plan provides ('larger monthly allowance and storage') and pointing to a pricing endpoint for tier choice. It leaves per-parameter syntax to the schema.

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?

Starts with a specific verb and resource: 'Create a Stripe Checkout link that subscribes the workspace to a plan.' It also states the return value ('Returns {url, sessionId}'), so the agent distinguishes it cleanly from the crawl/site siblings without opening the schema.

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?

Gives explicit conditions: caller must be OWNER or ADMIN, the workspace must be claimed by a person first, and the link is to be handed to the workspace owner. It also notes free credits exist without a plan, implicitly framing when a plan is actually needed.

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