← Registry

Developer Tools

gemmein.com

Provides searchable Gemmein documentation, SDK/API references, release changes, build guidance, and explanations of collection safety rules for developers.

1 endpoint71 known toolsFirst detected August 6, 2026Last detected October 6, 2026

ENDPOINT 1

https://api.gemmein.com/mcp

No auth detected

MCP server metadata

Name
gemmein
Version
0.17.0
Capabilities
tools
Server instructions

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

guide

Returns the Gemmein build guide (llms.

Inferred read-only
changes

Returns what changed in each Gemmein release newer than `since` (a Gemmein version, e.

Inferred read-only
reference

Returns the @gemmein/sdk API reference (REFERENCE.

Inferred read-only
search_docs

Searches the Gemmein docs for one term or phrase ('keyed create', 'ifVersion', 'addressed', 'expand') without reading a whole document.

Potential side effects
explain_rule

Explains 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-only
explain_error

Explains a GemmeinError code (err.

Inferred read-only
validate_collection_name

Checks a collection name against the naming law: lowercase letters, numbers, underscores; starts with a letter; 2-63 characters.

Inferred read-only
reaffirm_template

Returns reaffirm.

Inferred read-only
explain_relay

Validates a relay definition — the contents of gemmein/relays/<name>.

Inferred read-only
check_integration

Runs the reaffirm boundary checks live against the caller's own app; returns structured pass/fail (structuredContent: checks, notes, failedCount, passed).

Inferred read-only
app_status

Returns 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-only
pull

Returns what the app's Development holds as the gemmein/ file set (path → contents): its name, every collection's declaration, payments.

Inferred read-only
sync

Does 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 effects
declare_collection

Creates or updates one collection in Development from its declaration — exactly the JSON of gemmein/collections/<name>.

Inferred read-only
set_payments

Sets Development's plans and products from gemmein/payments.

Inferred read-only
put_relay

Creates or updates one relay in Development from gemmein/relays/<name>.

Inferred read-only
put_ai_tool

Creates or updates one AI tool in Development from gemmein/ai/tools/<name>.

Inferred read-only
put_ai_alias

Creates or repoints one model alias in Development (gemmein/ai/aliases.

Inferred read-only
put_email_template

Saves one email template in Development: name is sign-in (content = sign-in.

Potential side effects
rename_app

Names the app (it titles the customers' sign-in emails).

Inferred read-only
test_member_add

Makes a test member <name>@<tag>.

Inferred read-only
test_mail

Reads 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 effects
prove_app

Proves 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-only
test_pay

Pays 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-only
test_outcome

Returns 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-only
test_member_credits

Gives 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-only
test_member_suspend

Suspends 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-only
test_member_unsuspend

Lifts a test member's suspension in Development, at once with no approval — the dashboard's own unsuspend: they can sign in again.

Inferred read-only
test_member_cancel_subscription

Cancels 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-only
request_live_action

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

Potential side effects
live_action_status

Checks the approval request_live_action started; once the founder approved it, carries the action out — once — and answers what happened.

Inferred read-only
request_server_key

Asks 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 effects
dev_logs

Reads 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-only
dev_records

Reads 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 effects
dev_people

Reads 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 effects
dev_errors

Reads 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-only
dev_delete_collection

Deletes 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 effects
dev_delete_relay

Deletes 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 effects
dev_delete_ai_tool

Deletes 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 effects
dev_delete_email_template

Deletes 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 effects
relay_runs

Reads 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-only
replay_relay

Runs 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 effects
connect_payments

Says 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-only
provider_key

Says 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-only
site_draft

Opens 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-only
site_put_file

Puts one file into a site draft (draftId from site_draft): path is relative to the site's root (index.

Inferred read-only
site_publish

Publishes a site draft to the Development site (https://<slug>-dev.

Inferred read-only
site_status

Returns 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 effects
site_rollback

Makes 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-only
site_promote

Asks 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-only
site_download

Returns 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-only
site_read

Returns the site's files from Gemmein's own copy — the same stored files a publish deploys, never fetched from the address.

Potential side effects
site_share_link

Makes 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-only
site_history

Returns 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 effects
site_unpublish

Takes the Development site's private preview offline, the way the dashboard's Unpublish does: https://<slug>-dev.

Inferred read-only
site_revoke_previews

Turns 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-only
site_rebuild

Puts 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-only
domain_check

Returns 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-only
domain_connect_link

Returns, 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-only
live_overview

Reads 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 effects
live_errors

Reads 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-only
live_usage

Reads 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-only
live_webhooks

The 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-only
live_emails

Reads 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 effects
live_inbox

Reads 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-only
live_people

Reads the Live app's people (email, when they joined, last seen, suspended).

Potential side effects
live_revenue

Reads the Live app's business numbers: people (total, active in 30 days, suspended), subscribers by plan, refund-aware revenue per currency.

Potential side effects
live_subscriptions

Reads the Live app's subscriptions (who, which plan, status, period end).

Inferred read-only
live_records

Reads records of one Live collection, newest first (up to 50).

Inferred read-only
live_logs

Reads the Live app's Logs — stream auth, storage, manage or server — newest first (up to 100).

Inferred read-only
inbox_reply

Asks 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-only

CONNECT 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.

Indexed

Evidence is source-attributed and does not guarantee that a third-party server is safe. Risk labels are conservative metadata heuristics.