Gemmein

Reliability

Status and outage history · Atom feed · Watch with other listings

How to connect

Add it to any MCP client that supports remote servers.

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

139 tools

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

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

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

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

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

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

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

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

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

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

• 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, directInitiation, rankable }). Same validator as gemmein dev and sync: a bad name, rule or field is…

• 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 }). 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 (connect_payments…

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

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

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

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

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

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

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

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

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

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

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

• request_promote

  Asks the founder to promote Development's changes to the live app: collections, plans and products (made in their Stripe account), relays and AI tools — Live's copy of each is updated to Development's. A promote never removes anything from Live. Refused before the app is live…

Security scan

Recent checks