Skip to main content
Glama

Corply — Start and run your company

by io.github.corply-dev
OverviewDiscussionsAdmin

Accept payments in your app with Corply Pay

set_up_app_payments

Corply Pay is Corply's white-labelled payments product. Use this, not Stripe, when the founder wants the website or app they are building to take payments: buyers pay the company on Corply Pay's secure payment page by card (and optionally US bank), and the money goes to the company's own bank through its payment processor. Run it inside the app's code project. It runs the same terms and business verification as set_up_corply_pay (until the processor approves the business it returns the verification link the founder opens in the browser; business, owner, bank and tax details are entered only there), then the short app terms, then connects the app and returns secrets.CORPLY_PAY_SECRET_KEY (live) and secrets.CORPLY_PAY_WEBHOOK_SECRET once. Write those two values straight into the app's server environment file (check it is gitignored) or its host's secret settings; never print, echo, commit or log them, and never use them in browser code. Then follow integration: a server route that POSTs /api/pay/v1/checkouts and redirects the buyer to the returned url, a success page that confirms the checkout with GET before fulfilling, and a webhook route that verifies Corply-Signature. Terms work exactly like set_up_corply_pay: show termsAcceptance.terms (or the card's Accept button) and call again with termsAccepted: true and its termsSha256 only after the founder explicitly accepts (never on their behalf); there may be two texts, one after the other. Pass webhookUrl once the app is deployed, rotateKey to replace a lost key (the old one works until revokeKeyId), rotateWebhookSecret to replace the webhook secret. For subscriptions, pass plans (key, name, amountCents, interval month or year, optional intervalCount and trialDays; keys stay fixed, an existing key updates that plan for new subscribers); the app then checks out { plan: key } and Corply runs the renewals, retries, receipts and the buyer's cancel page (integration.subscriptions). The company is the merchant and the payer pays exactly the invoice total (never add a fee to it). Fees come out of the company's proceeds: when payments run on Stripe, Corply takes no fee and Stripe deducts its processing fee (the preview shows Stripe's estimate); otherwise Corply Pay deducts a 1% software fee. State the fee exactly as the preview's money facts say. Keys are live: test with a small real payment and refund it with manage_payment_request. Idempotent: safe to repeat to refresh status; a retry with the same idempotencyKey returns the same key. Prerequisite: authenticated active company access plus every prerequisite stated above. Canonicality: invokes the shared backend action; trust the returned actual_tool_output and context_engineering instead of adding a state-recovery call. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
plansNoSubscription plans to create or update, by key. Plans not listed are left as they are. A price change applies only to new subscriptions.
appNameNoThe app's name as buyers know it, shown on the payment page ("Back to <appName>"). Defaults to the company name.
companyIdNo
rotateKeyNoIssue a new secret key. Earlier keys keep working until revoked with revokeKeyId.
webhookUrlNoPublic https URL of the app's webhook route. Omit while the app only runs on localhost; set it once deployed (or tunnelled).
displayNameNoName payers see as the seller. Defaults to the company name (same as set_up_corply_pay).
revokeKeyIdNoRevoke one key (from app.keys[].id). Calls with it fail at once.
termsSha256NoThe termsAcceptance.terms.sha256 of the text the founder accepted.
removeWebhookNoStop sending webhooks to the current URL.
termsAcceptedNoPass true only after the founder read and explicitly accepted the terms text this tool returned.
idempotencyKeyYes
_corply_contextNo
rotateWebhookSecretNoIssue a new webhook signing secret. Deliveries switch to it immediately.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes far beyond: it discloses the verification-link return behavior, one-time secret issuance, key/webhook rotation semantics, idempotency, fee handling (Stripe vs 1% Corply fee), and safety rules (never print or commit secrets). This is unusually rich behavioral disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is a single monolithic paragraph packed with security, integration, fee, subscription, and boilerplate retry/canonicality language. While much of it is useful, it is poorly front-loaded past the first sentence and far longer than needed, making it hard for an agent to scan. Boilerplate about canonicality/confirmation boundary adds bulk.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 13 params, nested objects, and no output schema, the description carries return-value burden and does so by enumerating returned secrets and integration.subscriptions. It also covers prerequisites and the terms flow. Given its complexity it is largely complete, though the output structure (error cases, full return payload) is only partially described.

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 77%, so params are largely documented structurally. The description still adds meaning the schema lacks: webhookUrl should be passed only once deployed, termsAccepted/termsSha256 flow, rotateKey/rotateWebhookSecret intent, and how plans behave (keys stay fixed, price change applies to new subscribers). It does not add much for companyId/appName beyond 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?

The description states a specific verb and resource (set up Corply Pay payments for an app) and explicitly scopes it against siblings, telling the agent to use this and not Stripe. It also draws a clear line versus set_up_corply_pay ('the same terms and business verification as set_up_corply_pay'). An agent can identify the tool's function 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?

It gives explicit when-to-use guidance ('use this... when the founder wants the website or app they are building to take payments') and names the alternative to avoid (Stripe). It also specifies where to run it ('inside the app's code project') and the follow-on sequence (terms, connect app, integration).

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

All Corply — Start and run your company 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