The MCP server

If an AI tool is building your app, give it the whole Gemmein contract as tools inside the editor, with no tab-switching. @gemmein/mcp serves the guide, the reference, rule and error explainers, and a live check of your app's boundaries.

It's read-only against anything real: it can't touch live data, users, or config. (Its one live check runs in a development environment only: it mints throwaway test sessions and writes, reads, and deletes its own probe records there to prove your boundaries; nothing it makes persists, and live environments refuse it.) It teaches your agent to use @gemmein/sdk correctly, and proves the result.

Set it up

Claude Code:

claude mcp add gemmein -- npx -y @gemmein/mcp

Cursor, or any client that takes an mcpServers block:

{ "gemmein": { "command": "npx", "args": ["-y", "@gemmein/mcp"] } }

What your agent gets

• guide: the full builder's guide, covering auth flow, the seven safety rules, record shapes, links, uploads, contention, payments.
• reference: every SDK method, exact signature, return shape, and error code.
• search_docs: targeted search over both, when it needs one fact.
• explain_rule: any rule's contract, what it's right for, and the mistakes to avoid, or a cheat-sheet of all seven at planning time.
• explain_error: what a GemmeinError code means and exactly what to do about it.
• validate_collection_name: catches a misnamed collection before every read starts returning empty results.
• explain_relay: a gemmein/relays/<name>.json definition in, the sentence the dashboard would show out, or the one refusal naming the field; offline, over the eleven verbs write_record, grant_access, revoke_access, grant_credits, email_person, call_url, fulfil_product, refund_product, grant_plan, revoke_plan and start_run.
• reaffirm_template: the CI harness, ready to copy.
• check_integration: runs your isolation and access checks live against your own app and hands back structured pass/fail. Detailed below.

check_integration

check_integration runs the same boundary checks as the reaffirm CI harness, handed to your agent live, at build time. It proves that anonymous access is refused where it must be and that collection names are valid, and, with your dev secret key, it proves cross-user isolation with two throwaway test sessions. The result comes back as structured pass/fail, so the agent fixes what it finds before the app ships.

It catches the class of bug that passes with one user and breaks with two, the "everyone collapses onto the same record" mistake a single-user test never reveals. The surface it has to cover is small: apps talk to Gemmein in JSON through a rule-enforced API, with no query language, no enumerable schema, and no raw data layer to reach. The injection-and-enumeration attacks that start with "map the database" have no surface here, and the one real surface is the access rules, which is what this checks.

Give tools your pk_ public key, which on its own runs the anonymous checks. The cross-user isolation proof also needs an sk_dev secret: the development-only secret key you create in your dashboard. An sk_dev key works only against a development environment: it reaches no real user data, runs behind the same rules and rate limits as everything else, and the server refuses it on a live environment. Keep it in server env vars like any secret. sk_live keys are refused for test sessions, so this tooling cannot reach real users.