Gemmein

Connect Remote server

claude mcp add --transport http mcp https://api.gemmein.com/mcp

{
  "mcpServers": {
    "mcp": {
      "url": "https://api.gemmein.com/mcp"
    }
  }
}

{
  "servers": {
    "mcp": {
      "type": "http",
      "url": "https://api.gemmein.com/mcp"
    }
  }
}

Settings > Connectors > Add custom connector
URL: https://api.gemmein.com/mcp

Tools 80 found in our last check

• guide

  Returns the Gemmein build guide (llms.txt): the packaged contract — what code calls, matching the installed SDK. Useful before building an app on Gemmein, moving an existing app onto it, or deciding whether an app fits. The guide opens with two doors — starting from an idea with…

• changes

  Returns what changed in each Gemmein release newer than `since` (a Gemmein version, e.g. "0.22.1"), or the last three when `since` is left out: each change as was → now, with the error codes it added or removed. Useful when knowledge of Gemmein may be older than the installed re…

• reference

  Returns the @gemmein/sdk API reference (REFERENCE.md): every method, exact signature, return shape, and the stable error-code table. Useful while writing code against the SDK. With `topic` (a module or method: "g.collection", "checkout") it returns only the matching sections — t…

• search_docs

  Searches the Gemmein docs for one term or phrase ('keyed create', 'ifVersion', 'addressed', 'expand') without reading a whole document. Returns the docs site's matching sections first, best first — each a direct markdown link with its anchor (https://docs.gemmein.com/<page>.md#<…

• 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. Useful when choosing a collection's rule, or when a rule refus…

• explain_error

  Explains a GemmeinError code (err.code: conflict, forbidden, unknown_collection, invalid_shape, html_not_allowed, …): what the code means and the exact next step — including whether the refusal is final (a forbidden repeats on retry; the approach changes, not the request). Parse…

• validate_collection_name

  Checks a collection name against the naming law: lowercase letters, numbers, underscores; starts with a letter; 2-63 characters. Useful while planning collections, before any g.collection(name) call is written: a bad name throws from g.collection(name) before any network call —…

• reaffirm_template

  Returns reaffirm.mjs, the ready-to-edit harness that re-proves the app's boundaries against live Gemmein on every deploy (also shipped inside the @gemmein/sdk package): copied next to the app with its CONFIG block set, it runs in CI. Useful when wiring up the app's CI or handing…

• explain_relay

  Validates a relay definition — the contents of gemmein/relays/<name>.json — offline, before `gemmein sync` carries it to the cloud. A relay is the secure boundary for three jobs. React, nothing charged: a receiver (a provider's webhook), schedule (a clock), data_change (a record…

• check_integration

  Runs the reaffirm boundary checks live against the caller's own app on this Gemmein; returns structured pass/fail (structuredContent: checks, notes, failedCount, passed). Useful once the app is wired to Gemmein, when confirming it is done, and before go-live. It takes the app's…

• 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. Then its status across t…

• tools_map

  Returns a map of this connector's tools, in eight groups (start, build, test_dev, site, ask_live, read_live, customers, keys_and_billing): each group's purpose in one line, then each tool with a one-line "use it when…". With goal — take payments, put my site live, sign people in…

• pull

  Returns what the app's Development holds as the gemmein/ file set (path → contents): its name, every collection's declaration, payments.json, relays, AI tools and aliases, email templates. Useful in a project that has no gemmein/ folder yet, or before editing, to start from what…

• keys_list

  Lists every server key this app has — name, environment (development or, once live, live too), who made it, its access (collections and powers, never a Development/Live-wide "all" granted lightly) and when it was last used. The same list `npx gemmein keys list` and the dashboard…

• waiting_review

  Reads one post a test member wrote to a moderated collection ("publishing": "owner approves") before it's approved or sent back — its fields and its version (deciding it — approve or send back — is `npx gemmein approve`/`send-back`'s own job, outside the chat; this tool only rea…

• 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 nam…

• declare_collection

  Creates or updates one collection in Development from its declaration — exactly the JSON of gemmein/collections/<name>.json ({ rule, fields, unlockedBy, publishing, openFields, lockedFields, directInitiation, rankable }). Same validator as gemmein dev and sync: a bad name, rule…

• put_record

  Creates one record in a Development collection — the same back-office write the dashboard's own Add row makes. Owned/addressed/direct collections take ownerUserId/audienceUserId (a Development person's id). Once the app is live, request_create_record asks the founder instead.

• update_record

  Updates one Development record by id — the same door the dashboard's own edit sheet uses. data patches by default (a field left out is untouched); replace: true writes the whole document (a field left out is removed). Once the app is live, request_update_record asks the founder…

• dev_delete_record

  Deletes one Development record by id — the same door the dashboard's own delete button uses. Once the app is live, request_delete_record asks the founder instead.

• publish_record

  Publishes or unpublishes one Development record by id, on a collection with its own draft/published chip — the same door the dashboard's own chip uses. Once the app is live, request_publish_record asks the founder instead.

• set_payments

  Sets Development's plans and products from gemmein/payments.json's contents ({ plans, products, consent, mappings }). The file wins: a row edited in the dashboard is overwritten, and the answer lists every change first. Needs Stripe connected, which is the founder's step (connec…

• put_relay

  Creates or updates one relay in Development from gemmein/relays/<name>.json's contents ({ name, trigger, actions }); explain_relay validates the same definition offline. A signing or receiver secret Gemmein makes for it is not returned here — the answer carries the dashboard lin…

• put_ai_tool

  Creates or updates one AI tool in Development from gemmein/ai/tools/<name>.json's contents (label, provider, model or alias, credits, kind, instructions, inputs, bounds…). On an existing tool the dashboard's commerce (label, credits, lock, enabled) stands, as with sync. The AI p…

• put_ai_alias

  Creates or repoints one model alias in Development (gemmein/ai/aliases.json's { name: { provider, model } }).

• put_email_template

  Saves one email template in Development: name is sign-in (content = sign-in.json's JSON: logoUrl, brandColour, backgroundColour, appName, greeting), purchase, plan-start, notify or inbox-reply (content = the HTML). The same checks as sync; scripts and remote resources are stripp…

• put_view

  Creates or updates one view in Development from gemmein/views/<name>.json's contents ({ collection, filter?, sort?, columns?, totals?, layout, actions? }): one collection, a filter in the owner's own timezone, sort, the columns and totals it shows, its layout (table, cards, cale…

• rename_app

  Names the app (it titles the customers' sign-in emails). Before go-live it is Development's and changes at once; once live, the founder approves it in the browser (request_rename_app).

• test_member_add

  Makes a test member <name>@<tag>.gemmein.test in Development — their sign-in codes and every email the app sends them land in test_mail, never a real inbox. Test members sign in through the app's real screens and show the app works before hand-over. Made in Development only; 20…

• 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). to = a member's name; latest = only the newest. An email's text comes back inside <customer_text from="…" trust="untrusted"> and ag…

• 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. Use…

• test_run_ai_tool

  Sends one AI tool on provider external (a pipeline — your own server runs it) a test run: every declared input gets a placeholder value, and Gemmein signs and posts the hand-off to the tool's own URL, the same way a real run would. Answers acknowledged, completed, failed or time…

• test_pay

  Pays for a plan or product as a test member through the app's real checkout in Stripe's sandbox (test mode), to prove what the app does after a payment. outcome names what to prove: pays (a paid purchase), declined (Stripe declines it; nothing is granted) or asks_to_verify (Stri…

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

• test_refund

  Refunds a test member's sandbox payment in Stripe's test mode, to prove what the app does after a refund — the same sandbox `pay` (from test_pay) and the same kit's guards: a test-mode key only, a test member's own payment only. payment is the Stripe reference (pi_… or ch_…) fro…

• 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. Test members only (made with test_member_add); anyone else is refused, and it never reaches Live — Live's customers get credits thr…

• 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. For proving what the app shows a suspended person. Test members only (made with test_member_…

• 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. Test members only (made with test_member_add); anyone else is refused, and it never reaches Live. On the founder's Logs.

• 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 co…

• request_go_live

  Asks the founder to take the app live: its Development becomes the public Live app their customers use, on the Gemmein plan named (or the one the account already pays for). Going live is the founder's approval, then their payment for the plan in Stripe's own payment window on th…

• request_promote

  Asks the founder to promote Development's changes to the live app: collections (a new field arrives blank on existing records unless answered), plans and products (made in their Stripe account), relays and AI tools — Live's copy of each is updated to Development's. A promote nev…

• request_rename_app

  Asks the founder to rename the live app — the name titles every sign-in email its customers get. Before go-live, rename_app changes it at once. This is a change to how the business runs: your human approves it in their browser with the code Gemmein emails (and, when they set one…

• create_app

  Asks the founder to make another app on this same account, in Development only — a separate sandbox with its own collections, keys and settings, sharing nothing with this app's data. Refused once the account already has an app of that name or is at its cap. The new app has no co…

• request_add_domain

  Asks the founder to add one of their own domains to the live app. email: true also sends the app's email from mail.<domain> (on a domain already added for the web, that adds email to it). site: true shows the app's Gemmein Live site at it — only when the founder wants their Gemm…

• request_delete_domain

  Asks the founder to remove one of the app's domains: the app stops answering at it and stops sending email from it. This is a change to how the business runs: your human approves it in their browser with the code Gemmein emails (and, when they set one up, their authenticator app…

• request_accept_terms

  Asks the founder to accept Gemmein's terms for this app (going live needs them accepted). They read and accept the terms on the approval page. This is a change to one customer, so it is your human's approval alone: they approve it in their browser, and no emailed code is asked.…

• request_revoke_server_key

  Revokes one of the app's secret server keys by its name: a server that uses it is refused from then on. In Development this happens at once — no approval, no page. In Live it asks the founder to approve it in their browser first. For a Live key: This is a change to how the busin…

• request_replace_every_key

  Asks the founder to replace every key Gemmein issued for this app — Development and Live, in one action: every secret server key, every relay's Gemmein-minted signing secret, every external AI tool's signing secret, and the site preview link. Every old value stops working the mo…

• delete_app

  Asks the founder to permanently delete this project's linked app — this can't be undone. Every record, customer, file, site, domain, relay, AI tool and key goes; every active customer subscription is cancelled in Stripe at once (no refund by Gemmein); the founder's own connected…

• request_unpublish_site

  Asks the founder to take 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 and the Development preview is untouched; site_promote, or site_rebuild with env live, brings it back. site_unpub…

• request_delete_collection

  Asks the founder to delete Live's own copy of one collection. A Live collection that holds records is refused before asking — it is deleted on the dashboard. Development's copy is deleted at once with dev_delete_collection. This is a change to how the business runs: your human a…

• request_delete_relay

  Asks the founder to delete Live's own copy of one relay: Live's events no longer start it. Development's copy is deleted at once with dev_delete_relay. This is a change to how the business runs: your human approves it in their browser with the code Gemmein emails (and, when they…

• request_delete_ai_tool

  Asks the founder to delete Live's own copy of one AI tool: Live's calls to it are refused from then on. Development's copy is deleted at once with dev_delete_ai_tool. This is a change to how the business runs: your human approves it in their browser with the code Gemmein emails…

• request_grant_credits

  Asks the founder to give one Live customer credits: their balance goes up by amount, and note is the line their credit history shows. test_member_credits does the same for a test member in Development, at once. This is a change to one customer, so it is your human's approval alo…

• request_suspend_person

  Asks the founder to suspend one Live customer: they are signed out everywhere and can't sign in; their account, records and payments stay, and the founder can lift it on the customer's page. test_member_suspend does the same for a test member in Development, at once. This is a c…

• request_unsuspend_person

  Asks the founder to lift one Live customer's suspension: they can sign in again, nothing else changes. test_member_unsuspend does the same for a test member in Development, at once. This is a change to one customer, so it is your human's approval alone: they approve it in their…

• request_delete_person

  Asks the founder to delete one Live customer and their data — this can't be undone: their account, records, files and sign-in are erased, and a paid subscription they hold in Stripe is set to cancel at the end of the period they paid for. This is a change to one customer, so it…

• request_cancel_subscription

  Asks the founder to cancel one Live customer's subscription: a paid one is set to cancel in Stripe at the end of the period it paid for (Stripe charges nothing more); a comped plan ends at once. test_member_cancel_subscription does the same for a test member in Development, at o…

• request_create_record

  Asks the founder to create a record in one of Live's collections. Before go-live, put_record creates it at once. This is a change to one customer, so it is your human's approval alone: they approve it in their browser, and no emailed code is asked. Nothing changes until they app…

• request_update_record

  Asks the founder to update one of Live's own records. Before go-live, update_record changes it at once. This is a change to one customer, so it is your human's approval alone: they approve it in their browser, and no emailed code is asked. Nothing changes until they approve; app…

• request_delete_record

  Asks the founder to delete one of Live's own records — this can't be undone. Before go-live, dev_delete_record deletes it at once. This is a change to one customer, so it is your human's approval alone: they approve it in their browser, and no emailed code is asked. Nothing chan…

• request_publish_record

  Asks the founder to publish or unpublish one of Live's own records. Before go-live, publish_record changes it at once. This is a change to one customer, so it is your human's approval alone: they approve it in their browser, and no emailed code is asked. Nothing changes until th…

• request_app_lives

  Asks the founder to set whether the LIVE app lives on the web, as a mobile app, or both. Before go-live, set_app_lives changes it at once. This is a change to how the business runs: your human approves it in their browser with the code Gemmein emails (and, when they set one up,…

• request_email_switches

  Asks the founder to turn the LIVE app's outgoing emails and/or its new-sign-in notice on or off. Before go-live, set_email_switches changes it at once. This is a change to how the business runs: your human approves it in their browser with the code Gemmein emails (and, when they…

• request_email_sender_look

  Asks the founder to set the local-part word each kind of email sends from on the LIVE app's own verified domain: account, support and/or news. Before go-live, set_sender_words changes it at once. This is a change to how the business runs: your human approves it in their browser…

• request_google_signin_switch

  Asks the founder to turn the LIVE app's "Continue with Google" on or off for customers. Before go-live, set_google_signin changes it at once. This is a change to one customer, so it is your human's approval alone: they approve it in their browser, and no emailed code is asked. N…

• refund_steps

  Refunds are never made from a chat: Gemmein's Live Stripe key can't refund, by design. This reads one Live payment (its pi_… from live_revenue or the payment's Logs row) and answers your human's exact steps in Stripe — how much, to which customer, where to press Refund — and wha…

• live_action_status

  Reads where a Live request stands (one a request_* tool, inbox_reply, site_promote, site_rebuild or replay_relay with env live, a moderation tool with env live, domain_site on a Live app or request_server_key asked) — it changes nothing (approving it in the browser is what carri…

• 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. A Development key is made at once: the answer hands bac…

• 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 re…

• 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. Customer details (names, email addresses, messages, record contents) come only while the owner has "Customer details for…

• 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). Customer details (names, email addresses, messages, record contents) come only while the owner has "Customer detail…

• dev_errors

  Reads Development's Errors, the Logs page's own section: 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.gemmein.com/errors/<code>; null w…

• dev_view

  Reads one Development view's rows, exactly as its layout shows them (filtered, sorted, its declared columns) with its totals, and each row's own action buttons (the moves open to it right now). Customer details (names, email addresses, messages, record contents) come only while…

• 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). Never Live: a collection Live has stays in Live, and a promote never removes anything from Live — removing Live's is it…

• 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. Never Live: a relay Live has stays in Live, and a promote never removes anything from Live — removing Live's is its own requ…

• 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. Never Live: an AI tool Live has stays in Live, and a promote never removes anything from Live — removing Live's is its own request (r…

• dev_email_templates

  Lists Development's email templates (sign-in, purchase, plan-start, notify, notify-account, notify-event, email-person, inbox-reply) — each one's version and which {{vars}} it takes; with name, one template with its full saved source (sign-in: the sign-in.json brand config). Cha…

• dev_email_template_preview

  Renders one of Development's email templates (sign-in, purchase, plan-start, notify, notify-account, notify-event, email-person, inbox-reply) with sample data — the saved version, or, with html, that design instead (to check it before saving with put_email_template). Answers the…

• dev_email_template_test

  Sends ONE test of a Development email template (sign-in, purchase, plan-start, notify, notify-account, notify-event, email-person, inbox-reply) with sample data to the founder's OWN address only — never anyone else's, and never asked for here. Subject starts [Test]. Counts again…

Details

More developer tools servers See all

• AGILEX Docs

  Official AGILEX robotics product docs: manuals, CAN protocol, firmware, FAQ. Read-only.

• Echoo public catalog

  Read-only Echoo product facts, pricing, documentation and published writing skills.

• 99tests

  Order human-run real-device app tests from your coding agent; verified bugs return as fix prompts.

• LimitReceipts by aiw3b

  Find the AI coding/app-builder plan that fits your usage: limits, prices and plan-fit picks.

• Candor UI docs

  Candor UI docs and component suggestions. Read-only, no key, never serves paid source.

• MoneyTools Tools

  Call for a cheap read-only utility: 100+ tools; free daily tier; not charged on failure