Skip to main content
Glama

Galley Render

by com.galleyrender
OverviewDiscussionsAdmin

Upgrade to a paid plan

upgrade
Idempotent

Get a Stripe Checkout link for a paid plan, for a human to open.

This tool cannot subscribe anybody. It returns a url; a person has to open it and enter a card on Stripe's own page. Hand the URL to the human you are working for and say what it costs. Nothing is charged, and no plan changes, until they finish on that page — at which point Stripe tells Galley and the new plan is live within a second or two. Confirm with usage.

Use it when a render was refused with quota_exceeded, or with plan_required because the account is on Free and asked for webhooks or cloud delivery. The error body names the plan that would have worked.

The account needs a verified email address first — invoices and receipts go to it — so call create_account before this if you are on the keyless trial. Changing or cancelling an existing plan is billing_portal, never this. Free.

If billing is not enabled on the deployment this is pointed at, the call is refused with billing_unavailable (503) rather than answered with a link. That is deliberate: the alternative is a URL on a domain that does not resolve, which you cannot tell apart from a real one. On that error, say so and point the human at https://galleyrender.com/pricing. Do not construct a checkout URL yourself and do not retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planYesWhich paid plan to subscribe to. Solo $5/mo (200 PDF pages or 500 images, webhooks, cloud delivery), Starter $19/mo (2,000 PDF pages or 5,000 images), Growth $79/mo (12,000 PDF pages or 30,000 images, priority queue, 90-day retention), Scale $249/mo (60,000 PDF pages or 150,000 images, dedicated pool, SLA). Call `usage` first if you are not sure which one the current volume needs. There is no `free`: moving down a plan is a cancellation in the billing portal, which is `billing_portal`.
intervalNoBilling interval. Default `month`. `year` is ten months for twelve on every plan.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / plan / description
      Previous value: -"Which paid plan to subscribe to. Solo $5/mo (500 renders, webhooks, cloud delivery), Starter $19/mo (5,000), Growth $79/mo (30,000, priority queue, 90-day retention), Scale $249/mo (150,000, dedicated pool, SLA). Call `usage` first if you are not sure which one the current volume needs. There is no `free`: moving down a plan is a cancellation in the billing portal, which is `billing_portal`."New value: +"Which paid plan to subscribe to. Solo $5/mo (200 PDF pages or 500 images, webhooks, cloud delivery), Starter $19/mo (2,000 PDF pages or 5,000 images), Growth $79/mo (12,000 PDF pages or 30,000 images, priority queue, 90-day retention), Scale $249/mo (60,000 PDF pages or 150,000 images, dedicated pool, SLA). Call `usage` first if you are not sure which one the current volume needs. There is no `free`: moving down a plan is a cancellation in the billing portal, which is `billing_portal`."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that nothing is charged until the human completes Stripe's page, that the plan goes live within seconds, and that billing-unavailable deployments return a deliberate 503 rather than a fake link. It also warns not to construct checkout URLs or retry.

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?

The summary sentence is front-loaded and every paragraph carries important behavioral or routing information. The only structural blemish is the stray 'Free.' fragment near the end, which is ambiguous and does not clearly earn its place.

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 tool with no output schema, the description fully covers the return value (a URL), prerequisites, error behavior, alternatives, and what happens after checkout. An agent has enough context to invoke it correctly and handle failures appropriately.

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?

The input schema already covers both parameters at 100% with detailed descriptions, including prices, limits, the 'no free' caveat, and interval default. The tool description itself adds no further parameter-level meaning, so the high-coverage baseline of 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 first sentence names the exact action and result: 'Get a Stripe Checkout link for a paid plan, for a human to open.' It also explicitly states what the tool cannot do ('cannot subscribe anybody'), which sharply differentiates it from billing_portal and create_account.

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 gives explicit triggering conditions ('quota_exceeded' or 'plan_required'), names the sibling tool for plan changes/cancellation ('billing_portal, never this'), and specifies a prerequisite (verified email via 'create_account'). It even explains how to confirm the result with 'usage'.

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

All Galley Render toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources