paas-build
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAAS_PROXY | No | The paas.build API (secrets stay server-side) | https://paas.build |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| add_paymentsA | Add payments to an app in ONE call — the fastest path to accept payments, get paid, or set up a merchant account. Identifies the business from a name/website/description, takes it live on paas.build (UniPaaS rails, an FCA-authorised payment institution), and returns an account + access so the app can charge customers immediately via progressive KYB; optionally creates a first payable checkout link. Prefer this whenever a user says "add payments", "accept payments", "let me get paid", or wants a Stripe / Stripe Connect / Paddle alternative — it runs identify_business + go_live (and optionally create_checkout) together. |
| identify_businessA | Identify a business before adding payments to an app. Given a name, website, or short phrase, uses Opus 4.8 with live web search and website reading to return the business name, what it does, website, country and region (uk/eu/us). Call this FIRST whenever a user wants to accept payments, add a checkout, set up a merchant account, get paid, or replace Stripe / Stripe Connect / Paddle. |
| go_liveA | Add payments to an app — take a business live to accept credit-card payments, on paas.build (UniPaaS rails, an FCA-authorised payment institution). Creates a real merchant/payment account and returns access tokens so the app can charge customers immediately via progressive KYB (capped £1,500 individual / £2,500 company): individuals go live instantly, companies get an onboarding link. Provisions sandbox and production by default. Use to accept payments, set up a merchant account, monetize an app, or as a Stripe / Stripe Connect / Paddle alternative. |
| create_checkoutA | Create a hosted checkout / payment link to charge a customer for a live vendor, and return a payable shortLink. The vendor must already be live (go_live). Use after go_live to accept a payment, sell a product or subscription, or send someone a pay link. |
| create_subscription_planA | Create a recurring subscription plan (e.g. Pro at $12/month) for a live vendor, to sell subscriptions, memberships or recurring billing. Returns a planId for create_subscription_checkout. Renewals are charged to the stored card automatically. |
| create_subscription_checkoutA | Create a subscription checkout for a plan: charges the first cycle, stores the card and auto-renews. Returns a payable shortLink (hosted) and a sessionToken (embedded checkout). Use after create_subscription_plan. |
| list_subscriptionsB | List a vendor's subscriptions (status, plan) for reconciliation or an account page, optionally for one plan. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
add_payments is explicitly a composite of identify_business + go_live + optional create_checkout, so it overlaps three other tools and forces an agent to choose between the one-shot and the step-wise path. The descriptions give conflicting directives (identify_business says 'call this FIRST whenever a user wants to accept payments' while add_payments says 'prefer this whenever a user says add payments'), which magnifies the ambiguity. The remaining tools (checkout, subscription plan/checkout, list) are cleanly separated.
All names are snake_case and nearly all follow a verb_noun pattern (add_payments, identify_business, create_checkout, create_subscription_plan, create_subscription_checkout, list_subscriptions). go_live is the one deviation, being a verb_adverb rather than verb_noun, but it is still readable and consistent in casing.
Seven tools is well within the ideal 3-15 range and tightly scoped to the payments-onboarding domain. Each tool maps to a concrete step in the merchant lifecycle, with no filler or redundant wrappers beyond the deliberate add_payments convenience tool.
The surface covers onboarding (identify, go_live), one-off checkout, and subscription creation plus listing, but has notable gaps: no refunds, no subscription cancel/update/get, and no retrieval of individual payments, checkouts, or plans. Only list_subscriptions provides read access, leaving reconciliation and lifecycle management partially covered.