Mmcp.market

Supero MCP server

by supero-platform·io.github.supero-platform/supero·v2.0.0

Build multi-tenant apps over MCP. Schemas, CRUD, deploys — access control enforced server-side.

B83/100grade B
What users say
No reviews yet
Be the first
Safety scan
B83/100

full report

Adoption
Growing

0 stars

Reviews

Write one

Nobody has reviewed Supero yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Supero tools (64, 15 write)

write = sends, deletes, buys or posts
  • apikey_get_scopeFree

    Get the scope and permissions of the current API key.

  • build_bind_data_sourceFree

    Bind source streams to the app's schemas. mode='live_read' (default: read-only BYODB / warehouse), 'live_readwrite' (BYODB read+write — DOMAIN-ADMIN only), or 'sync' (copy into SuperoDB). For live modes, discovery must have run and each binding's `source` must match a discovered stream; the bind VERIFIES the live mapping materialized. Bound live schemas are read/written via ORDINARY app CRUD — nothing goes in the bundle.

  • build_configure_servicesFree

    Configure a service's keys for the project so an integration works at deploy (e.g. wire SendGrid for email, a Stripe TEST key for checkout). TEST/SANDBOX keys ONLY. Keys with a clear live marker (Stripe sk_live_… / Razorpay rzp_live_…) are auto-refused, but most providers give NO test-vs-live signal — so for EVERY provider send test/sandbox keys only and use the admin panel for production secrets (a deep link is returned). Never put a real secret through this tool/chat. Reacts to the live permission result; secret values are never echoed.

  • build_connect_data_sourcewrite actionFree

    Create a data connector to an EXTERNAL source the app owner controls (their own database, a REST API, or a warehouse). Returns a connector_id. Does NOT bind schemas yet — run build_discover_source then build_bind_data_source. Credentials are sent to the platform and NEVER echoed back; prefer read-only DB creds / the Key Store for production. Requires a domain- or project-admin API key.

  • build_create_projectwrite actionFree

    Create a NEW project (domain-admin keys only; plan-gated). Mints the project's schema_namespace + an API key (returned ONCE). Use for a fresh app.

  • build_deploywrite actionFree

    Deploy a published version. target='cloud_ephemeral' (managed Cloud Run, ~30m throwaway preview; requires platform enablement; the default when cloud deploy is enabled) or 'local' (hand the user the bundle to run with the project's own key). For a PERMANENT public URL, use build_go_live instead.

  • build_deploy_statuswrite actionFree

    Poll a cloud deploy started by build_deploy or build_go_live. Pass the poll_url it returned. Reports elapsed_s since launch; a launch still pending after ~5 minutes should be treated as failed.

  • build_discover_sourceFree

    Discover a connector's schema: trigger discovery, wait, and return the source streams (names, columns, primary keys), AI-inferred Supero schemas, field mappings, and a suggested namespace. Run AFTER build_connect_data_source and BEFORE build_bind_data_source (a live bind's `source` MUST equal a discovered stream name).

  • build_doctorFree

    PREFLIGHT a bundle BEFORE publish/deploy — catches the silent deploy-killers build_validate does NOT: missing #supero-preloader removal (app stuck on a spinner forever), heavy startup seed (Cloud Run port-bind timeout → 'container failed to start'), reserved field names like status/state (silently dropped), namespace collisions (ambiguous reads), and services needing elevated import permission. Run it after build_validate and before build_publish.

  • build_e2e_testwrite actionFree

    Run the FULL behavioural test suite against a PUBLISHED bundle in the project's OWN already-deployed app (no throwaway project is created) — auth/RBAC/multi-tenant, CRUD round-trips, workflows + event emission, services, aggregates, real-browser UI. WRITE-SAFE: on a DEV project the write suites create + delete only their OWN test records (your real data stays read-only); a LIVE project is auto-restricted to read-only suites so production data is never mutated. This is the deep complement to build_smoke_test ('loads + reads one row'); it proves the app actually WORKS. COSTS A FULL RUN (~2-4 min of real compute) — a PRE-DELIVERY gate, NOT a per-edit check; run it after build_validate + build_doctor pass, on a deployed + seeded project. ASYNC: returns a run_id; poll build_e2e_test_status. Findings are layer-attributed so you know which are yours to fix (app/config) vs. report (platform/sdk). Requires platform enablement.

  • build_e2e_test_statusFree

    Poll an e2e run started by build_e2e_test. While running, returns status only. When complete, returns a compact report: verdict (honest — never 'healthy' if a core suite couldn't run), per-suite pass/fail/warn/skip, findings with layer + fix hint, what was/wasn't covered, and next_steps that say which findings to fix vs. report. On failure it carries a cause.

  • build_get_bundleFree

    Fetch the CURRENT (or a given) PUBLISHED bundle: the file list + a signed download_url, or ONE file's content inline via file=. For ANY change request on an existing app, START from this bundle and modify it — re-authoring from scratch silently drops the hand-authored ui/app.js and every prior fix.

  • build_get_examplesFree

    Fetch a COMPLETE, production-quality reference app (schemas.py + config.py + setup.py + ui/app.js) to copy patterns from — the single biggest lever for app quality. archetype='index' (default) lists the available archetypes with per-file byte sizes; pick the one closest to your app ('commerce-marketplace' | 'service-booking' | 'ops-dashboard' | 'multitenant-portal' | 'saas-billing') and fetch it BEFORE authoring your UI. These are real 'stunning' apps; mirror how they compose the SDK components, art-direct the landing page, and structure schemas. Optional file= to fetch just one file ('schemas.py' | 'config.py' | 'setup.py' | 'ui/app.js'). Responses are PAGED (~32KB/section): when the header says more:true, fetch the next section with offset=<next_offset> — never re-fetch from 0.

  • build_get_projectFree

    Get one project's details: schema_namespace (use this EXACT value as the `namespace` literal on every schema dict), last published version, AND the captured `project_intent` — the brief (project_description/summary), the discovered data model (entities/central_entity/relationships/status_workflows), and the landing intent (public_landing_view). BUILD TO THIS — it's the authoritative app spec the user already gave; don't re-ask or ignore it.

  • build_get_service_contractFree

    Fetch the AUTHORITATIVE contract for a transactional/stateful platform service (cart, order, payment, booking, appointment, membership, approval, document_signature, recurring_plan, inventory, task, ticket, loyalty_points, rental, comment, attachment, feedback, notification, product, service, customer, workflows). Returns the service's state machine (initial_state + transitions), its operations (op ids + input fields + resulting state), the base schemas + mandatory fields you must supply, AND the platform's DEFAULT UI SCHEMAS for that service — the bulletproof reference for building a correct, sophisticated transactional UI. ALWAYS call this for any service your app `extends` BEFORE authoring its UI — do not guess op names, states, or mandatory fields from prose. service_id='index' (default) lists all services.

  • build_get_skillsFree

    Fetch a Supero build reference. doc='skills' (default, the spec you MUST follow) | 'components' (the real pre-built SDK component/global catalog — read so you don't reinvent UI) | 'rubric' (the rich-app quality checklist — what 'stunning' means) | 'landing' (compact landing-page derivation + quality bar — MANDATORY read for public-facing apps) | 'integrations' (the EXACT services.* wrapper→service_id→args map for email/sms/stripe/ai/etc.) | 'web' / 'transactional' / 'workflows' / 'mobile' / 'services' (deep companion docs) | 'e2e_testing'. Returns the doc + a content version + the SDK floor to pin. Read 'skills' FIRST, then 'components' + a matching build_get_examples before you author UI. Docs are PAGED (~32KB/section): when the header says more:true, fetch the next section with offset=<next_offset> — never re-fetch from 0.

  • build_go_liveFree

    PERMANENT deploy: promote a published version to a PERMANENT public URL at <service>.supero.live (managed Cloud Run) — unlike build_deploy(target='cloud_ephemeral'), which is a ~30-min throwaway. If version_uuid/file_id are omitted, the latest published version for the project is used. Returns public_url + poll_url; poll with build_deploy_status until live, then build_smoke_test the public_url. build_teardown removes it. Requires a domain- or project-admin API key + platform cloud-deploy enablement.

  • build_list_bound_schemasFree

    Classify this project's schemas: which are connector-backed vs app-authored, and each one's access mode (sync | live-ro | live-rw | warehouse). Use it so you DON'T render create/edit UI for read-only live sources (live-ro/warehouse) or regenerate/overwrite connector-discovered schemas.

  • build_list_capabilitiesFree

    List the platform's available services/integrations from the LIVE catalog (email, sms, slack, ai, stripe_checkout, google_oauth, push_notification, …) — so the intake's 'which connections/integrations?' question is accurate and you never guess a service id. Returns each service's exact catalog `service_id` (use it verbatim in config.py `services` — e.g. 'stripe_checkout', NOT 'stripe'), category, whether it needs a key, and YOUR connection's service permissions (can_import / can_configure). Descriptive — what EXISTS, never what to use. Pass service_id for one service's config fields.

  • build_list_data_sourcesFree

    List the external DATA SOURCE types an app can connect to — its own Postgres/MySQL/MSSQL/Oracle/MongoDB, any REST API, or a Snowflake/BigQuery/Redshift/Databricks/ClickHouse/Fabric warehouse — plus the curated public-API catalog. Read this to offer a 'connect your own data' option. Flow: build_connect_data_source → build_discover_source → build_bind_data_source. See build_get_skills(doc='connectors').

  • build_list_projectsFree

    List projects you can build into (uuid, name, schema_namespace, live_url).

  • build_logsFree

    Fetch recent Cloud Run logs for a project's deployed app — THE tool for diagnosing a failed/stalled cloud deploy or a crashing app (startup-probe timeouts, tracebacks, 'container failed to start on PORT'). Read-only; rate-limited per domain.

  • build_planFree

    PLAN FIRST — turn a one-line app idea into an explicit BUILD CHECKLIST before you author anything, so a thin prompt doesn't silently skip what expert builders add (this is exactly why first-draft apps miss detail pages, tenant pickers, seed data). Deterministic, no LLM: it detects the app's VERTICAL and returns the authentic page structure + terminology for that domain, which entities need a full DETAIL PAGE, the multi-tenant login pattern (picker + tenant=''), seed guidance, and which build_get_examples to copy. Call it right after build_get_skills and BEFORE authoring.

  • build_publishwrite actionFree

    Package + upload your authored bundle and record a version under the project. Returns version_uuid + file_id + download_url. Runs build_validate first unless force=true. Provide files as {relative_path: content}.

  • build_recommend_integrationsFree

    RECOMMEND which concrete provider integrations this app needs, and WHY — the deterministic Step-2 intelligence the web wizard uses, now over MCP. Pass the app `description` + the platform `service_ids` it will use (e.g. ['cart','order']); returns GROUPED, TIERED suggestions (required/recommended/optional) with the default option flagged — e.g. cart/checkout → a payment gateway (REQUIRED; stripe_checkout default, paypal/razorpay offered), customer-facing apps → transactional email, appointments+reminders → sms. Options are drawn ONLY from the LIVE installed manifests, so it can't suggest a provider you don't have. PRESCRIPTIVE complement to build_list_capabilities (which is descriptive): call this so you don't OMIT a needed integration; use build_list_capabilities for a service's exact id + config fields.

  • build_replace_projectFree

    DESTRUCTIVE (DOMAIN-admin keys only): completely replace a DEV-mode project's app — wipes its data (retains credentials, API keys, namespace, tenant). Refused if mode='live'. Requires confirm_project_name to match. If you pass files, they are VALIDATED before any wipe (a bad bundle is a no-op) and published after; otherwise wipe-only, then call build_publish.

  • build_run_data_sourcewrite actionFree

    Trigger a SYNC RUN on a data connector and return the run id. MCP-created connectors are trigger:manual, so a mode='sync' binding copies NO rows until a run executes — call this after build_bind_data_source (and again whenever the source data changes). Live-read/warehouse bindings don't need runs (they read the source directly).

  • build_set_project_modeFree

    Set a project's build mode. 'dev' (default) allows COMPLETE REPLACE (wipe data, keep credentials); 'live' protects it. Switch to dev before replacing, to live when it's in production.

  • build_smoke_testFree

    VERIFY a DEPLOYED app actually works (not just 'running'). HTTP-checks the live URL: root loads with a title, app.js is your bundle (not a stub) and dismisses the boot splash, config.js namespace matches the project; optionally logs in and reads an entity to confirm data + no namespace ambiguity. Pass url= (from build_deploy_status) or poll_url=. THE post-deploy gate — run it after every deploy.

  • build_stage_bundleFree

    PUB-1a: get the out-of-band UPLOAD endpoint for a LARGE app bundle that won't fit inline (the model's max OUTPUT tokens cap `files`/`files_b64gz`, so big apps otherwise have to be truncated/minified). Upload a gzip(json {path:content}) blob to the returned URL with your OWN key, then pass the returned file_id as `files_ref` to build_validate / build_publish / build_doctor. Bundle size then no longer depends on any token cap.

  • build_teardownFree

    Tear down a project's live deployment — BOTH the permanent (build_go_live) app and the ephemeral preview — DELETEing the managed Cloud Run services and freeing their URLs. Idempotent: a project with nothing deployed returns stopped=true. ONLY manages Supero-hosted apps — a project deployed to your own AWS/GCP is refused, not silently reported stopped. Check `stopped`: false means the teardown was INCOMPLETE and the app may still be serving (and billing) — re-run it, do not report success. Requires a domain- or project-admin API key.

  • build_update_projectwrite actionFree

    Update a project's metadata (display_name, description, show_public, live_url).

  • build_validateFree

    Validate a locally-authored bundle against the live platform BEFORE publishing. AST-only (your code is never executed). Checks manifest, syntax, import-safety, config exports, schema validity, and namespace==project schema_namespace.

  • build_whoamiFree

    Resolve your API key's scope: role (domain_admin/project_admin), domain, whether you can create projects, and your plan. Call this to decide the flow.

  • connector_cancelwrite actionFree

    Cancel a running connector execution.

  • connector_disableFree

    Disable a connector.

  • connector_discoverFree

    Trigger schema/metadata discovery for a connector.

  • connector_discover_resultsFree

    Get discovery results.

  • connector_discover_statusFree

    Get discovery execution status.

  • connector_enableFree

    Enable a connector for scheduling.

  • connector_pluginsFree

    List available connector plugins.

  • connector_runwrite actionFree

    Trigger a manual connector sync execution.

  • connector_statusFree

    Get connector status and recent executions.

  • connector_testFree

    Test an existing connector's connectivity.

  • connector_test_configFree

    Test a connector configuration.

  • crud_createwrite actionFree

    Create a new object in the current domain. Use schema_list to see available types and their fields.

  • crud_deletewrite actionFree

    Delete an object from the current domain.

  • crud_getFree

    Get a specific object by UUID from the current domain.

  • crud_searchFree

    Search/list objects of any type in the current domain. Use schema_list first to discover available object types. System types: project, tenant, user_account, api_key, connector, audit_log, schema_registry, client_sdk, connector_execution, connector_plugin. Domain types vary per domain (e.g. customer, invoice, appointment, vehicle).

  • crud_updatewrite actionFree

    Update an existing object in the current domain.

  • project_link_schemasFree

    Link schemas to a project. Accepts schema UUIDs or names.

  • rbac_check_permissionFree

    Check if the current user has a specific permission.

  • rbac_get_my_accessFree

    Get current user's role, permissions, and scope.

  • schema_deletewrite actionFree

    Delete a schema from the domain. Use with caution.

  • schema_getFree

    Get full details of a specific schema by UUID. Returns the complete schema definition including all attributes and metadata.

  • schema_listFree

    List all existing schemas in the current domain.

  • schema_list_projectFree

    List schemas linked to the current project.

  • schema_saveFree

    Save/upload schemas to the domain. Schemas are validated before saving. Returns list of successfully saved schemas with their UUIDs. IMPORTANT: Pass FLAT schema objects directly — do NOT wrap in schema_content. The tool handles schema_type detection and wrapping automatically. Required fields: name, parent_type, prefix, plural_name, attributes, description. Supported attribute types: 'string' for text, 'float' for decimal numbers (NOT 'number'), 'integer' for whole numbers, 'boolean' for true/false. Optionally pass project_uuid to auto-link saved schemas to a project. Example: { "schemas": [{ "name": "product", "description": "Product catalog entry", "parent_type": "tenant", "prefix": "prd", "plural_name": "products", "attributes": [ {"name": "title", "type": "string", "required": true}, {"name": "price", "type": "float"}, {"name": "stock", "type": "integer"} ] }] }

  • schema_updatewrite actionFree

    Update an existing schema definition.

  • schema_validateFree

    Validate schemas before saving. Checks for conflicts with existing schemas, circular dependencies, reserved names, and parent_type correctness. Always validate before saving!

  • sdk_downloadFree

    Get download URL for an SDK.

  • sdk_generateFree

    Generate client SDKs for the domain's schemas.

  • sdk_listFree

    List available SDKs for the current domain.

  • sdk_statusFree

    Check SDK generation request status.

Public scan report

scanner v0.1.9 · 2026-09-20 · same rubric, same numbers if you re-run it

no findings
  • Code scanremote-only server, no package to scann/a
  • Live reliabilityremote reachable in 3152ms17/20
  • Tool poisoning64 tool descriptions checked15/15
  • Auth qualityAPI key sent as a header8/15
  • Maintenancelast push 13 days ago15/15
  • Maintainer identityregistry namespace matches repository owner7/10
Overall 83/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

Install directly

claude mcp add --transport http supero https://api.supero.dev/mcp/v1/messages
Add to Cursor

Supero: common questions

Is Supero MCP server safe?
Mostly: it is graded B (83/100). Read the Supero safety report
How do I install Supero?
It runs remotely at api.supero.dev. Add it to Claude Code, Claude Desktop or Cursor with the snippets above, or call it through the mcp.market gateway without installing anything.
Does Supero need an API key?
Yes. The registry entry asks for X-API-Key.
Is Supero maintained?
The last commit was 14 days ago (2026-09-06). The latest release is v2.0.0.
Is Supero up?
100% of our last 5 checks got an answer. We check remote servers about four times a day.

More from supero-platform