The same tier and subscription_status fields appear on the init_core_memories response so the AI knows the operator's plan on the very first turn. This eliminates a follow-up account(info) call when the AI just needs to know whether a feature is reachable. For deeper context (capabilities, available transitions, supporter badge), account(info) is the dedicated lookup.

unit_amount_cents and currency come from Stripe at request time (the worker fetches each price_ ID and returns the current amount). Display name, description, and capability unlocks are static metadata maintained alongside the SKU registry so marketing copy never drifts from what the AI presents to the user. Changing a Stripe price in the dashboard is the only edit needed to roll out a price change.

Stripe's Checkout is a hosted page that collects card data, runs fraud checks, completes Strong Customer Authentication where required, and returns a signed completion event via webhook. Embedding card collection in the MCP channel would require taking on PCI compliance, fraud surface, and SCA flow handling that the AI cannot meaningfully complete on the user's behalf. The single-click handoff is both safer (the user sees what they're paying for on Stripe's UI before the charge) and simpler (no payment plumbing in the AI client).

Step 1: The AI hits a tier wall.

Step 2: The AI confirms tier and presents options.

The AI presents the two relevant SKUs in plain language: "To create shared collections you'll need Pro at $25/month. To write to existing shared collections, Plus at $7/month is enough."

Step 3: The user picks. The AI mints the URL.

The AI hands the URL to the user: "Click this to upgrade to Pro monthly: https://checkout.stripe.com/c/pay/cs_live_...". The user clicks, enters their card on Stripe's hosted page, completes payment, and is redirected back.

Step 4: The webhook fires. Tier flips.

Stripe sends checkout.session.completed to the worker. The worker reads metadata.sku_id from the session, resolves the matching tier grant from the SKU registry, and PATCHes the backend's /account/by-customer/…/tier endpoint. The backend updates gnosis_accounts.tier and invalidates its settings cache synchronously. Wrapper's 60-second tier cache expires within the minute (or is busted on the next init_core_memories, whichever comes first).

Step 5: The originally-blocked operation now works.

The entire journey runs through the AI. The user clicked once, on a Stripe-hosted page, and never left their chat client.

Paid tools (collection_manage, agent_manage) are stubbed for free callers so the LLM can discover what's reachable on a higher tier without being able to call them. The account tool is the inverse: it's how that discovery becomes actionable. Hiding it from Free callers would defeat the purpose. The same tool is returned to every tier.

The five operations (info, plans, checkout, portal, donate) are tightly coupled — they share an audience (the upgrade-recommender LLM), a domain (Stripe-backed billing), and a usage envelope (returns URLs, never charges). Listing five tools instead of one bloats the tool advertisement that every LLM reads on every call and makes the surface harder to learn. One tool with an action argument matches the signal and collection_manage patterns the rest of the surface already uses, and keeps the LLM's tool-selection step constant size as new account operations are added.

The worker endpoints these actions call (/api/account/subscription, /api/plans, /api/checkout, /api/billing-portal, /api/donate) accept three authentication paths:

• Browser session cookie (existing path, untouched).
• OAuth Bearer access token (for MCP clients holding the user's token directly).
• Internal worker-secret + X-User-ID (used by the pod's MCP wrapper when it proxies tool calls on behalf of the calling user).

Same identity payload shape on the worker side regardless of which path was used. The wrapper uses the third path because it doesn't hold the user's access token at the python-service hop; it holds the shared worker secret that already gates every internal proxy route.

The capabilities returned by account(info) mirror the tier matrix maintained server-side. Free: 500 memories, 0 agents, no shared-collection writes. Plus: 5,000 memories, read and write to shared collections (no admin/create). Pro: unlimited memories (subject to service quality rate limits), unlimited agents, collection creation and administration. Permanent tiers (Benefactor / Founder / internal developer accounts) sit at or above Pro and are immune to webhook tier changes. The matrix is the single source of truth; the MCP action surfaces it without re-deriving.

The earlier surface exposed five separate tools: subscription_info, available_plans, start_checkout, manage_subscription, and start_donation. Those names are still recognized by the MCP wrapper and transparently rewritten to the matching account action, so existing clients keep working without code changes. New integrations should call account directly.