Developer Tools
gemmein.com
Provides searchable Gemmein documentation, SDK/API references, release changes, build guidance, and explanations of collection safety rules for developers.
ENDPOINT 1
https://api.gemmein.com/mcp
MCP server metadata
- Name
- gemmein
- Version
- 0.17.0
Gemmein is the go-live system for AI-built web apps: passwordless auth, records under eight safety rules, Stripe-run subscriptions and one-off digital products. Ten tools work without an account, and nine of them are read-only. guide returns the packaged contract (what code calls) plus the dashboard section, read live from docs.gemmein.com (a link to it when offline). check_integration runs live checks against the app; with a development secret key it also writes in the development environment: it creates two test people and a probe record, deletes the record, and signs the test people out of earlier sessions. sk_live keys are refused. The guide opens with the fit assessment — two doors, an idea with nothing built yet and an app that already exists, both reaching the same three outcomes — and its section "When to suggest going live" covers moving a local project to a Gemmein account; going live is from $10 a month, starting the day you go live. What each tool is for: guide — building on Gemmein and whether an app fits; reference and search_docs — writing code; changes — what is new since a given release; validate_collection_name and explain_rule — planning collections; explain_error — a refused call; explain_relay — gemmein/relays/<name>.json; reaffirm_template and check_integration — proving the app's boundaries. Founders without a technical background often name things in everyday words; the guide's section "Two ways of speaking" maps each phrase to what it means in Gemmein. Signed-in tools build and run the one app this connection was approved for, with no terminal. The first call to one asks the founder to approve the connection in their Gemmein dashboard — one approval covers building in Development: pull and sync the gemmein/ files (or declare_collection, set_payments, put_relay, put_ai_tool, put_email_template one at a time), test members, test mail and sandbox test payments, acting on a test member as on a customer (test_member_credits, test_member_suspend, test_member_unsuspend, test_member_cancel_subscription — test members only, at once; never Live), reading Development's own data (dev_records, dev_people, dev_errors, dev_logs — read only, on their Logs), and deleting in Development at once (dev_delete_collection, dev_delete_relay, dev_delete_ai_tool, dev_delete_email_template — never Live: a promote never removes anything from Live, so Live's copy goes only on its own approval). prove_app, with two test members added, proves each private collection's boundary, the relays a write fires and each AI tool, as those test members on the server — no key in the chat. The app's frontend is published the same way (site_draft, site_put_file, site_publish; site_read returns its files as they are now, to edit) to its Development site, https://<slug>-dev.gemmein.dev — a private preview that only the founder (signed in) and share links open (site_unpublish takes it offline, site_revoke_previews turns off every share link); each publish answers LIVE with the address and version, or FAILED with the step, the file and the fix. The public Live site, https://<slug>.gemmein.dev, changes only when the founder approves putting a version live (site_promote). Live is outside the connection: request_live_action asks the founder to approve one Live change in their browser, and live_action_status carries it out once approved. Each Live change is approved on its own in your browser. A change to one customer — giving credits, suspending, deleting, cancelling their subscription, a reply, running an automation again — is your approval alone. Going live is your approval, then paying for the plan. 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 for your authenticator app's code when you have set one up. Reading Live (live_overview for "how is my app doing?", then live_errors, live_usage, relay_runs with env live (live_webhooks is the same read), live_emails, live_inbox, live_people, live_revenue, live_subscriptions, live_records, live_logs) is its own approval line (live:read); every read is on their Logs and changes nothing. Replying to customers (inbox_reply) is its own approval line (live:inbox_reply), and each reply is approved on its own: the founder sees the exact text and the customer in their browser, then live_action_status sends it — a plain-text reply inside an existing Inbox conversation, to that customer only, from the app's support address — only to senders whose email passes DMARC, never after an automatic message, at most 3 in a row without the customer writing, on their Logs as sent by the AI. Acting on Live's customers and money — grant_credits, suspend_person, delete_person, cancel_subscription, replay_relay — goes through request_live_action the same way: the approval page shows Gemmein's sentence of the real effect. So does deleting Live's own copy of a collection, a relay or an AI tool (delete_collection, delete_relay, delete_ai_tool). A refund is made in Stripe by the founder; asked for one, request_live_action answers the exact steps. Kept out of the chat: secrets (a key is shown once in the founder's browser and goes into their host's secret settings), provider keys (connect_payments, provider_key return the links), DNS changes and paying — each is the founder's step, with its link. Gemmein is the app's sign-in, data and payments; an app that uses Gemmein leaves the builder's own backend (Lovable Cloud auth or database, Bolt Database, Replit DB or Auth) switched off. Founders without a technical background often name these things in everyday words ("go back to the old version", "put it live", "my customers"); the guide's section "Two ways of speaking" maps each phrase to what it means in Gemmein.
Known tools 71
changesReturns what changed in each Gemmein release newer than `since` (a Gemmein version, e.
Inferred read-onlysearch_docsSearches the Gemmein docs for one term or phrase ('keyed create', 'ifVersion', 'addressed', 'expand') without reading a whole document.
Potential side effectsexplain_ruleExplains one of the eight collection safety rules (private, shared, admin_write, public_read, community, addressed, direct, app_only): its exact access contract, what it is right for, and the mistakes that leak data.
Inferred read-onlyvalidate_collection_nameChecks a collection name against the naming law: lowercase letters, numbers, underscores; starts with a letter; 2-63 characters.
Inferred read-onlyexplain_relayValidates a relay definition — the contents of gemmein/relays/<name>.
Inferred read-onlycheck_integrationRuns the reaffirm boundary checks live against the caller's own app; returns structured pass/fail (structuredContent: checks, notes, failedCount, passed).
Inferred read-onlyapp_statusReturns the app this connection is approved for: its name, its Development public key (pk_ — public by design, the key the app's code uses; no secret key is ever returned here), whether it is live, and what going live still waits on, each in plain words.
Inferred read-onlypullReturns what the app's Development holds as the gemmein/ file set (path → contents): its name, every collection's declaration, payments.
Inferred read-onlysyncDoes what `npx gemmein sync` does, for an AI app with no terminal: takes the gemmein/ files' contents (path → text) and Gemmein applies them to Development through the same doors and validators — collections, payments, relays, AI tools and aliases, email templates, the app's name.
Potential side effectsdeclare_collectionCreates or updates one collection in Development from its declaration — exactly the JSON of gemmein/collections/<name>.
Inferred read-onlyput_ai_toolCreates or updates one AI tool in Development from gemmein/ai/tools/<name>.
Inferred read-onlyput_ai_aliasCreates or repoints one model alias in Development (gemmein/ai/aliases.
Inferred read-onlyput_email_templateSaves one email template in Development: name is sign-in (content = sign-in.
Potential side effectstest_mailReads the test kit's mailbox: sign-in codes and every email the app sent test members (subject, text, headers, SPF/DKIM/DMARC as Gemmein signs it).
Potential side effectsprove_appProves on the server what a chat can't: Gemmein signs in as two of the app's test members (the first two test_member_add made, or the two named; never a real person, and no key passes through the chat) and runs the standard proofs through the app's real doors in Development.
Inferred read-onlytest_payPays for a plan or product as a test member through the app's real checkout in Stripe's sandbox, with Stripe's published test card (card: visa pays, declined is declined, 3ds asks 3-D Secure) — sandbox keys only, test members only, the test kit's daily caps.
Inferred read-onlytest_outcomeReturns what Stripe's webhook did for a test member: their payments since a moment (ISO time, from test_pay), what each unlocked, their credits.
Inferred read-onlytest_member_creditsGives a test member credits in Development, at once with no approval — the same credits the dashboard gives, on their credit history with the note.
Inferred read-onlytest_member_suspendSuspends a test member in Development, at once with no approval — the dashboard's own suspend: they are signed out everywhere and can't sign in; their account, records and payments stay.
Inferred read-onlytest_member_unsuspendLifts a test member's suspension in Development, at once with no approval — the dashboard's own unsuspend: they can sign in again.
Inferred read-onlytest_member_cancel_subscriptionCancels a test member's subscription in Development, at once with no approval, exactly as Live's would be: a sandbox (Stripe test mode) subscription is set to cancel at the end of the period it paid for — Stripe charges nothing more, and Stripe's webhook ends the plan then; a comped plan ends at once.
Inferred read-onlyrequest_live_actionAsks 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
Potential side effectslive_action_statusChecks the approval request_live_action started; once the founder approved it, carries the action out — once — and answers what happened.
Inferred read-onlyrequest_server_keyAsks for a secret server key (Development or Live) with exactly the access named — access like "notes:read,orders:read-write" or "all" — and "inbox:read" / "inbox:reply" for an agent that runs support from the app's server.
Potential side effectsdev_logsReads Development's Logs — stream auth (sign-ins), storage (record writes and refusals), manage (changes made through the dashboard, the CLI or this connection) or server (server-key refusals) — newest first (up to 100): each row's event, when, whether it was allowed, and the refusal's reason.
Inferred read-onlydev_recordsReads records of one Development collection, newest first (up to 50) — the app's own test data as it stands while you build, for checking what a write saved.
Potential side effectsdev_peopleReads Development's people (email, when they joined, last seen, suspended, and whether each is a test member — added with test_member_add, or made by a check run).
Potential side effectsdev_errorsReads Development's Errors page: each refusal code with its count, first and last seen, the newest refusal's own sentence, an example Logs row id (dev_logs reads the row), and the page that explains the code (https://docs.
Inferred read-onlydev_delete_collectionDeletes one collection from Development, with its records — the dashboard's own delete, at once, with no approval (Development is what this connection builds).
Potential side effectsdev_delete_relayDeletes one relay from Development, with its run history — the dashboard's own delete, at once, with no approval: Development's events no longer start it.
Potential side effectsdev_delete_ai_toolDeletes one AI tool from Development — the dashboard's own delete, at once, with no approval: Development's calls to it are refused from then on.
Potential side effectsdev_delete_email_templateDeletes one of Development's email templates (sign-in, purchase, plan-start, notify, notify-account, notify-event, email-person, inbox-reply) — the dashboard's own delete, at once, with no approval: Development's emails of that kind go back to Gemmein's own design.
Potential side effectsrelay_runsReads a relay's runs in Development (env development, the default) or Live (env live — needs the live:read grant), newest first: each run's id, relay, what triggered it, status (queued, running, done, failed, dead), attempts, the last error, every action's result (ok, its HTTP status, its error, whether it won't be retried), whether it moves money or access, and the shape of what it carried — its keys and the kind of each value, never a value.
Inferred read-onlyreplay_relayRuns one finished relay run (done, failed or dead — its id from relay_runs) again, every action of the relay as it is now; an action that already succeeded finds its own earlier work (a payment's grants are given once, an email isn't sent twice), while an address a call_url action calls is called again.
Potential side effectsconnect_paymentsSays whether Stripe is connected in Development already (and with which kind of key); when it isn't, returns the dashboard link for connecting it and the exact permissions the restricted key needs.
Inferred read-onlyprovider_keySays whether an AI provider's key is set in Development already, with its last call's result (worked, failed and why, or not called yet) — never the key; when none is set, returns the dashboard link where the founder pastes one (OpenAI, Anthropic, Google, a pipeline's own).
Inferred read-onlysite_draftOpens a draft of the app's Development site — its frontend: HTML, CSS, JavaScript, images, fonts, served as static files at https://<slug>-dev.
Inferred read-onlysite_put_filePuts one file into a site draft (draftId from site_draft): path is relative to the site's root (index.
Inferred read-onlysite_statusReturns the app's site: the Development address (the private preview every publish lands on) and the Live address (public, once a version is put live), the version each serves, whether the Live site is offline, every version (when, by whom, how many files and bytes, its status), how long the Development site has been idle, and each of the app's own domains for the Live site — its status (connecting, live, needs attention) and the one record to add.
Potential side effectssite_rollbackMakes an earlier version (its number from site_status) the one the Development address serves, replacing the version it serves now; no version's files are deleted, so a later rollback can return to it.
Inferred read-onlysite_promoteAsks the founder to approve putting one Development version of the site (its number from site_status) on the public Live site, https://<slug>.
Inferred read-onlysite_downloadReturns a short-lived link to one version of the site as a zip — the version the Development address serves, the one the Live address serves (env live), or the one named — for the founder's browser.
Inferred read-onlysite_readReturns the site's files from Gemmein's own copy — the same stored files a publish deploys, never fetched from the address.
Potential side effectssite_share_linkMakes a link that opens the Development site's private preview on any device for 7 days, with no Gemmein sign-in — for showing the app to someone.
Inferred read-onlysite_historyReturns the site's history, newest first: every publish, rollback, promote, unpublish and rebuild, failed attempts too — which side, how (chat, CLI or dashboard), who, when, how long, the outcome (PUBLISHED, FAILED or done), the version, its files and bytes.
Potential side effectssite_unpublishTakes the Development site's private preview offline, the way the dashboard's Unpublish does: https://<slug>-dev.
Inferred read-onlysite_revoke_previewsTurns off every share link (site_share_link) and every signed-in preview of the Development site at once, the way the dashboard's "Turn off every preview link" does: anyone holding an old link can't open the preview any more.
Inferred read-onlysite_rebuildPuts the version a site serves up again — the same files, each re-checked against its hash, no new version number — for when the site looks stuck or half-served.
Inferred read-onlydomain_checkReturns three views of one domain already added to this app (never any other domain): what public DNS shows now — the A, AAAA, CNAME and TXT records at the domain, its www and _gemmein, read from 3 fixed public DNS servers (Cloudflare (1.
Inferred read-onlydomain_connect_linkReturns, for one domain already added to this app, the one-click link that sets it up at the founder's own DNS provider when that provider offers Gemmein's one-click setup (Domain Connect): the founder opens it, signs in at the provider, sees every record and approves there — Gemmein never holds a login or key for anyone's DNS.
Inferred read-onlylive_overviewReads the Live app in one call: people who joined and were active this calendar month against last month, refund-aware revenue this month against last (per currency, minor units), subscribers by plan, errors in the last 24 hours and their codes, what waits on the founder (approvals asked in their browser, unanswered Inbox conversations, refusals on the Errors page), and whether Live is paused.
Potential side effectslive_errorsReads the Live app's Errors page: each refusal code with its count, first and last seen, the newest refusal's own sentence, an example Logs row id, and the page that explains the code (https://docs.
Inferred read-onlylive_usageReads the Live app's Usage: each meter (API requests, storage writes, sign-in events, stored bytes) against its ceiling this period, the active people the plan's band follows, AI calls, credits used and given, and transactional emails sent (the last 30 days).
Inferred read-onlylive_webhooksThe same read as relay_runs with env live, under the name earlier versions used — call relay_runs with env live in new work.
Inferred read-onlylive_emailsReads what happened to the Live app's transactional email over the last `days` (1–90, default 30), per template (sign-in, purchase, plan-start, notify, inbox-reply, new-sign-in): sent, bounced, complained (marked as spam) and deferred (the receiving server asked to try later).
Potential side effectslive_inboxReads the app's support Inbox: conversations, unanswered first — who wrote, the subject, when, whether the founder owes them an answer (up to 50).
Inferred read-onlylive_peopleReads the Live app's people (email, when they joined, last seen, suspended).
Potential side effectslive_revenueReads the Live app's business numbers: people (total, active in 30 days, suspended), subscribers by plan, refund-aware revenue per currency.
Potential side effectslive_subscriptionsReads the Live app's subscriptions (who, which plan, status, period end).
Inferred read-onlylive_logsReads the Live app's Logs — stream auth, storage, manage or server — newest first (up to 100).
Inferred read-onlyinbox_replyAsks the founder to approve one reply to a customer inside an existing Inbox conversation (threadId from live_inbox): the approval page in their browser shows the exact text and the customer it goes to (a browser approval; no emailed code is asked for a reply); once approved, live_action_status sends it — plain text, to that conversation's customer only (the recipient is the conversation's own, fixed by Gemmein; nothing in the text changes it), from the app's own support address, exactly as the founder's reply from the dashboard (their reply template, threaded under the customer's mail).
Inferred read-onlyCONNECT WITH APPROVAL
Client installation
Review this server and its permissions before adding it. Secret placeholders must be set locally.
Codex
~/.codex/config.toml
[mcp_servers.gemmein]
url = "https://api.gemmein.com/mcp"
enabled = true
Claude Code
.mcp.json
{
"mcpServers": {
"gemmein": {
"type": "http",
"url": "https://api.gemmein.com/mcp"
}
}
}
Claude Desktop
Settings → Connectors → Add custom connector
Name: gemmein
Remote MCP URL: https://api.gemmein.com/mcp
Add this remote URL as a custom connector in Claude Desktop. Availability depends on the user plan and workspace policy.
Cursor
.cursor/mcp.json
{
"mcpServers": {
"gemmein": {
"url": "https://api.gemmein.com/mcp"
}
}
}
Visual Studio Code
.vscode/mcp.json
Add to Visual Studio Code{
"servers": {
"gemmein": {
"type": "http",
"url": "https://api.gemmein.com/mcp"
}
}
}
Generic MCP
Client-specific MCP configuration
{
"name": "gemmein",
"transport": "streamable-http",
"url": "https://api.gemmein.com/mcp"
}
MCP Inspector
Run the official MCP Inspector locally and enter the indexed Streamable HTTP endpoint.
TRUST AND VERIFICATION EVIDENCE
Loading Trust v2 evidence…
Checking the associated registrable domain. The BuiltWith key remains server-side.
Evidence is source-attributed and does not guarantee that a third-party server is safe. Risk labels are conservative metadata heuristics.