Payments & procurement

Safeguard's MCP server includes four billing tools that let a connected agent run the complete procurement journey against the same self-serve payment APIs the web app's billing page uses. An agent can discover the plans offered to your workspace (with correct regional pricing), compare tiers and what each unlocks, start a Stripe Checkout session, and verify afterwards that the invoice settled and the tier's features activated.

All four tools are opt-in per tenant — an administrator enables them via their per-tool feature flags (mcp:tool:safeguard_purchase_plan, etc.) in the admin console. Only the 10 core tools are on by default; a workspace turns on exactly the billing tools it wants (e.g. enable pricing/invoice reads but leave safeguard_purchase_plan off to forbid agent-initiated checkout).

New here entirely without an account? The account-onboarding tools (safeguard_create_account, safeguard_login, safeguard_verify_email, safeguard_resend_verification) are available pre-auth on the dedicated /mcp/onboarding endpoint — create the account, sign the session in, then continue below.

Regional pricing

Plans are priced per region. safeguard_list_pricing_plans accepts every location signal the agent knows about its user — not just a country code:

{
  "location": {
    "country_name": "India",
    "locale": "en-IN",
    "timezone": "Asia/Kolkata",
    "continent": "Asia",
    "city": "Bengaluru",
    "district_or_state": "Karnataka",
    "currency": "INR",
    "ip_address": "203.0.113.9"
  }
}

The server resolves these offline to a single pricing country (precedence: explicit ISO code → country name → locale region → timezone → unambiguous currency) and the response states which signal decided the region and why others were ignored. Signals that can't safely pick one country — a continent alone, a city alone, an IP alone — fall back to GLOBAL pricing rather than guessing. No location data leaves the MCP server; only the resolved country code reaches the pricing API.

Tiers and audiences

Each plan carries a tier (for example PRO, MAX, 5X, 20X, ENTERPRISE) and an audience category:

• INDIVIDUAL — single-user plans
• TEAM — team plans
• ENTERPRISE — enterprise plans
• SHARED — offered to every audience

Pass audience to filter (SHARED plans are always included), and read each plan's feature list to compare what the tiers unlock. After a purchase activates, the tier's features are enabled as feature flags — verify with safeguard_get_subscription_entitlements.

The purchase flow

1. Discover — safeguard_list_pricing_plans with the user's location and (optionally) audience. Pick a plan id.
2. Checkout — safeguard_purchase_plan with plan_id and optional interval (month or year; yearly saves 20% when no explicit yearly price is set). The tool returns a Stripe-hosted payment URL.
3. Pay — the user (or a saved payment method) completes payment on Stripe's page. Card data never passes through the MCP server, the agent, or the model.
4. Activate — on payment, the subscription activates automatically: usage limits raised, product license granted, tier feature flags enabled, paused scans resumable.
5. Verify — safeguard_list_billing_invoices shows the invoice as paid (the procurement receipt), and safeguard_get_subscription_entitlements lists the features now enabled.

Tenant isolation

The purchase, invoice, and entitlement tools take the tenant from the authenticated session context. There is no tenant argument — an agent can only buy for, and see the invoices and entitlements of, the workspace it is signed into.

Auditing

Every billing call — including read-only plan, invoice, and entitlement pulls — emits a structured audit record (billing.plans.list, billing.checkout.create, billing.invoices.list, billing.entitlements.get) with tenant, organization, user, parameters, and outcome. Tokens and card data are never logged. The durable money-event trail (subscription activated, license granted, activation failures) is written by the payment activation flow to the platform audit log.

Troubleshooting