request_live_action

com.gemmein/mcp · Verify this server

Asks the founder to approve one Live action in their browser — go_live, promote, rename_app, add_domain, delete_domain, accept_terms, revoke_server_key, site_promote (target: a Development site version — site_promote asks the same way), site_rebuild_live (target: the version the Live site serves — site_rebuild with env live asks the same way), unpublish_site (target: the version the Live site serves — takes the public Live site offline: its address and the app's own domains show a plain "This site is offline" page, every version and file is kept, the Development preview is untouched; site_rebuild with env live, or site_promote, brings it back); deleting Live's own copy: delete_collection (target: its name — one holding records is deleted only on the dashboard), delete_relay and delete_ai_tool (target: its name) — Development's is deleted at once with dev_delete_collection, dev_delete_relay, dev_delete_ai_tool, and a promote never removes anything from Live; Live's email templates come only from Development by promote, so there is no Live delete for one; and on Live's customers and money: grant_credits (plan { person: email or id, amount: whole credits, note: one line saying why }), suspend_person (plan { person: email or id }), delete_person (plan { person: email or id }), cancel_subscription (plan { person: email or id }), inbox_reply (plan { threadId: from live_inbox, text: the reply, plain text }), replay_relay (plan { event: the run's id from relay_runs }). A connector never holds Live power: the founder approves exactly this in their browser — a change to one customer (credits, suspending, deleting, cancelling their subscription, a reply, running an automation again) is their approval alone; going live is their approval, then paying for the plan, with no code; a change to how the business runs (a promote or a Live push, products and prices, domains, email, Stripe, keys, relays and AI tools, the Live site) also asks for the code Gemmein emails and, when they set one up, their authenticator app's code — and only then does live_action_status carry it out, once. The approval page shows Gemmein's own sentence of the real effect (who, how much, what ends), read against Live when asked; a plan that no longer matches Live when carried out is refused. plan is the exact request body where the action takes one (go_live: {}, promote: the promote body; add_domain: {"email": true} to send the app's email from mail.<domain> too — on a domain already added for the web, that adds email to it). A refund is never made from a chat (Gemmein's Live Stripe key can't refund): asked with action refund_payment and plan { payment: "pi_…" }, the answer is the founder's exact steps in Stripe and what Gemmein does once Stripe confirms it. Never from a chat — each is the founder's on the dashboard: customer details for AI assistants, revealing or rotating keys, sender domains, deleting the app or the account. Payouts and Stripe settings are the founder's, made in Stripe. A Gemmein account is one person, so there is no team or ownership to change; retention follows Gemmein's Privacy Policy and DPA (there is no setting; questions go to hello@gemmein.com); bulk changes across every customer are never made from a chat, and Gemmein doesn't send bulk email. Returns the approval link for the founder and a handle for live_action_status. This is what a founder may call putting it live, publishing their changes or making it real.