Servidor MCP de Gemmein

• Nombre en el registrocom.gemmein/mcpverificado en el registro MCP

El nombre en el registro está bajo gemmein.com. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-28
• Herramientas138
• El servidor se llamagemmein
• Versión del servidor0.20.1
• Versión del protocolo2025-06-18

El 2026-10-28 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 299 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.
• Comprobado 6 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 6 hasta ahora
• Uso523 descargas en npm por semana
• Respondiómidiendo6 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta304 ms
• Espacio en el contexto del agente≈ 36.160 tokenslas definiciones de todas sus herramientas (139), que el agente lleva en cada turno
• Definiciones de herramientasA · 93 de 100
• Resultados tipados0 de 139 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Parámetros sin descripción: en 57 de 139

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y números →

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 how the business runs: your human approves it in their browser with the…

• request_revoke_server_key

  Asks the founder to revoke one of the app's secret server keys by its name: a server that uses it is refused from then on. The key's value never passes through this chat. This is a change to how the business runs: your human approves it…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Las primeras 60 de 138, en el orden del servidor.