GitHub
server ทางการของ GitHub ให้ AI อ่านและจัดการโค้ด issue และ pull request ในบัญชีของคุณได้ ใช้ผ่านคลาวด์ของ GitHub หรือรันในเครื่องด้วย Docker ก็ได้
คำอธิบายจากผู้ทำ (ภาษาอังกฤษตามต้นฉบับ)
Build and deploy multi-tenant apps from ChatGPT, Claude or your editor. Sign in with OAuth or a key.
สามเรื่องนี้ไม่รวมเป็นคะแนนเดียว เพราะความเห็น การวัด และความนิยม เป็นคนละเรื่องกัน
ตัวนี้ยังไม่ได้เรียบเรียงเป็นภาษาไทย ด้านล่างคือข้อเท็จจริงที่เราอ่านจาก registry
เลือกโปรแกรม AI ที่คุณใช้ แล้วคัดลอกค่าตั้งไปวาง
ต้องเตรียมก่อน
คุณใช้แอปไหน
เลือกแอปด้านบน เราจำไว้ให้ ครั้งหน้าปุ่มจะขึ้นว่า “ติดตั้งลง …”
ใช้ได้ทั้ง Claude บนเว็บ แอปคอมพิวเตอร์ และมือถือ:
https://mcp.supero.dev/mcpพิมพ์คำสั่งนี้ใน Terminal
claude mcp add --transport http supero https://mcp.supero.dev/mcpวางในไฟล์ .cursor/mcp.json ของโปรเจกต์ หรือ ~/.cursor/mcp.json
{
"mcpServers": {
"supero": {
"url": "https://mcp.supero.dev/mcp"
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
วางในไฟล์ .vscode/mcp.json ของโปรเจกต์
{
"servers": {
"supero": {
"type": "http",
"url": "https://mcp.supero.dev/mcp"
}
}
}เบราว์เซอร์จะถามก่อนเปิดแอป จากนั้นแอปแสดงค่าตั้งให้ตรวจแล้วกดยืนยัน ช่อง key เว้นว่างไว้ให้คุณใส่เอง
ChatGPT ต่อได้เฉพาะ server ที่อยู่บนอินเทอร์เน็ต:
https://mcp.supero.dev/mcpชื่อเมนูอาจต่างกันเล็กน้อยตามแพ็กเกจและรุ่นของแอป
ตัวเลือกเก็บในคุกกี้บนเครื่องนี้ ไม่ต้องมีบัญชี
ค่าตั้งนี้สร้างจากข้อมูลใน registry ของผู้ทำ ถ้าไม่ตรงกับ README ให้เชื่อ README
ชื่อและคำอธิบายเครื่องมือตามที่ server ตอบมาเมื่อ 7 พ.ย. 2569 ผู้ทำเป็นคนเขียน ไม่ใช่เรา แสดงเป็นข้อความล้วน
build_get_skillsFetch 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
build_get_examplesFetch 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 a
build_planPLAN 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 detect
build_get_service_contractFetch 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, prod
build_whoamiResolve 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.
build_list_projectsList projects you can build into (uuid, name, schema_namespace, live_url).
build_get_projectGet 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/relationship
build_create_projectCreate 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_update_projectUpdate a project's metadata (display_name, description, show_public, live_url).
build_set_project_modeSet 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_replace_projectDESTRUCTIVE (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 bund
build_validateValidate 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_publishPackage + upload your authored bundle and record a version under the project. Returns version_uuid + file_id + download_url. Runs build_validate first; force=true overrides soft errors only. Provide files as {relative_path: content}.
build_stage_bundlePUB-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,
build_get_bundleFetch 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 a
build_deployDeploy 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_
build_deploy_statusPoll a cloud deploy started by build_deploy or build_go_live. Pass the poll_url it returned. Reports elapsed_s since launch. 'launching' for 5-6.5 minutes is normal (Cloud Run IAM propagation): keep polling every ~30s and probe the url once it appears. Only a persistent unreachab
build_logsFetch 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_go_livePERMANENT deploy: promote a published version to a PERMANENT public URL at .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. Re
build_teardownTear 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 projec
build_list_capabilitiesList 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
build_recommend_integrationsRECOMMEND 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 (requ
build_configure_servicesConfigure 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
build_import_servicesIMPORT platform services into a project (e.g. 'workflows', 'email', 'stripe_checkout', 'cart', 'order', 'payment') so the app can call them and its event-bound workflows can run. Uses the platform's service import with YOUR connection's credential. Reports each service's exact ou
build_doctorPREFLIGHT 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 stat
build_auditSECURITY + CORRECTNESS AUDIT of a bundle BEFORE go-live (static; your code is never executed). Finds what build_validate/build_doctor do not: MONEY-01 client-chosen checkout amounts, AUTHZ-01 end-users able to write server-owned fields (paid/issued/status/amount/payment refs) or
build_verifyACCEPTANCE TEST of your app's running PREVIEW (after build_deploy, before build_go_live). Where build_audit reads the code, build_verify USES the deployed preview like a buyer would, with throwaway test accounts (verify- @example.com, deleted afterwards): health (serves, app.js =
build_smoke_testVERIFY 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 nam
build_e2e_testRun 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 t
build_e2e_test_statusPoll 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 nex
build_list_data_sourcesList 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' optio
build_connect_data_sourceCreate 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. Flow: build_connect_data_source → build_discover_source (lists the tables/streams; needs this connector_id) →
build_discover_sourceDiscover 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 `sourc
build_bind_data_sourceBind 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). Modes by source: postgresql, supabase, mysql take all three; mssql takes sync and live_read;
build_run_data_sourceTrigger 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 binding
build_list_bound_schemasClassify 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 sc
crud_searchSearch/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 d
crud_getGet a specific object by UUID from the current domain.
crud_createCreate a new object in the current domain. Use schema_list to see available types and their fields.
crud_updateUpdate an existing object in the current domain.
crud_deleteDelete an object from the current domain.
schema_listList all existing schemas in the current domain.
schema_getGet full details of a specific schema by UUID. Returns the complete schema definition including all attributes and metadata.
schema_validateValidate schemas before saving. Checks for conflicts with existing schemas, circular dependencies, reserved names, and parent_type correctness. Always validate before saving!
schema_saveSave/upload schemas into a project. Schemas are validated before saving and linked to the project. Returns the saved schemas with their UUIDs; skipped schemas carry the platform's reason. IMPORTANT: Pass FLAT schema objects directly — do NOT wrap in schema_content. The tool handl
schema_deleteDelete a schema from the domain. Use with caution.
schema_list_projectList schemas linked to the current project.
schema_updateUpdate an existing schema definition.
project_link_schemasLink schemas to a project. Accepts schema UUIDs or names.
sdk_generateGenerate client SDKs for the domain's schemas.
sdk_statusCheck SDK generation request status.
sdk_listList available SDKs for the current domain.
sdk_downloadGet download URL for an SDK.
rbac_get_my_accessGet current user's role, permissions, and scope.
rbac_check_permissionCheck if the current user has a specific permission.
apikey_get_scopeGet the scope and permissions of the current API key.
connector_runTrigger a manual connector sync execution.
connector_cancelCancel a running connector execution.
connector_statusGet connector status and recent executions.
connector_enableEnable a connector for scheduling.
เราตรวจจากข้อมูลที่ใครก็เปิดดูได้ ยังไม่ได้อ่านโค้ด ข้อที่ไม่เกี่ยวกับตัวนี้ไม่นับในตัวหาร · ตรวจเมื่อ 8 พ.ย. 2569
ชื่อใน registry ยืนยันด้วยบัญชี GitHub supero-platform ซึ่งเป็นเจ้าของ repo
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ยังไม่ได้อ่านข้อมูล repo จาก GitHub
ตอบกลับใน 199 ms (HTTP 200)
ไม่ต้องล็อกอิน
อ่านคำอธิบายเครื่องมือ 60 ตัวแล้ว ไม่พบคำสั่งแอบแฝงถึง AI
เทียบกับทุก server ที่ยังใช้งานในหมวดนี้ทั้งทะเบียน ดาวนับเฉพาะเมื่อผู้ลงทะเบียนเป็นเจ้าของ repo
จากการตรวจเบื้องต้นของเรา ผ่าน 3 จาก 3 ข้อที่ตรวจได้ เรายังไม่ได้อ่านโค้ด ก่อนใส่กุญแจหรือ token ให้ดูว่า server ขอสิทธิ์อะไร และเลือกกุญแจที่ทำได้เท่าที่จำเป็น
registry ไม่ได้ระบุว่าต้องใช้กุญแจ แต่บางตัวจะขอให้ล็อกอินตอนใช้ครั้งแรก
รันบนคลาวด์ของผู้ทำ ต่อผ่านอินเทอร์เน็ตได้เลย ไม่ต้องลงโปรแกรม แต่ข้อมูลที่ส่งให้จะผ่านเซิร์ฟเวอร์ของผู้ทำ
repo บน GitHub มีการแก้โค้ดล่าสุด – และส่งรุ่นล่าสุด (2.0.2) เข้า registry วันนี้
โปรแกรมที่รองรับ MCP เช่น Claude Desktop, Claude Code, Cursor และ VS Code ตัวนี้ต่อผ่าน URL จึงใช้กับโปรแกรมที่รับ remote MCP ได้ เช่น ChatGPT ที่เปิดโหมดนักพัฒนา
ในหมวดเดียวกันมี GitHub, Desktop Commander, Cloudflare MCP
server หมวดเดียวกันจากผู้ทำคนอื่น เรียงตามดาว
อ่านการ์ด:↓ ดาวน์โหลดต่อสัปดาห์i★ ดาว GitHubiสามเสา: รีวิว · ผลตรวจ · การใช้งานiอัปเดต = วันที่ส่งรุ่นล่าสุดเข้า registryi
server ทางการของ GitHub ให้ AI อ่านและจัดการโค้ด issue และ pull request ในบัญชีของคุณได้ ใช้ผ่านคลาวด์ของ GitHub หรือรันในเครื่องด้วย Docker ก็ได้
MCP server for terminal commands, file operations, and process management
ส่วนนี้คัดจาก repo ของผู้ทำตามต้นฉบับ PopNx MCP ไม่ได้ตรวจหรือรับรองเนื้อหา ตัด HTML รูปภาพ และสคริปต์ออกแล้ว ลิงก์จะพาออกนอกเว็บ
Build and deploy a real web app from your AI assistant, using Supero over MCP.
You describe the app. Your assistant (Claude Code, Cursor, VS Code Copilot, or any MCP client) reads the build spec from Supero, writes the app, validates it, and deploys it to a URL you can open. The app gets sign-in, roles, a database, an admin panel and an API from the platform, so the assistant writes the part that is yours and nothing else.
This repo has three things:
The free plan gives you 3 projects and needs no card. Deployments on it are 30-minute previews; a URL that stays up is a paid plan.
| If you want to | Go to |
|---|---|
| Build your first app, with every step spelled out | [Your first app, step by step](docs/first-app.md) (30 minutes) |
| Choose something to build | Picking a project, then the project list |
| See a finished example with its source | Page Turners, a book club app |
| Fix something in an app that exists | Community apps |
| Read about a platform feature | Learn more on docs.supero.dev |
The rest of this page is the short version for people who have done this before.
| Key | What the assistant can do with it | Use it when |
|---|---|---|
| Project key | Build into one project, and only that one | You have made a project in the dashboard and want the app there. This is the safer default. |
| Domain key | Create new projects and build into them | You want the assistant to create the project too. Needs a domain admin. |
The key starts with ak_ and is shown once. Copy it then. If you lose it, rotate it under API Keys to get a new one.
Treat the key like a password. Do not commit it, and do not paste it into an issue or an app folder.
The server is at https://api.supero.dev/mcp/v1/messages (streamable HTTP). Send the key in an X-API-Key header, raw, with no Bearer in front.
Claude Code
claude mcp add --transport http supero \
https://api.supero.dev/mcp/v1/messages \ --header "X-API-Key: ak_..."
Then run /mcp inside Claude Code and check that supero is connected.
Cursor: ~/.cursor/mcp.json
{
"mcpServers": { "supero": { "url": "https://api.supero.dev/mcp/v1/messages", "headers": { "X-API-Key": "ak_..." } } } }
VS Code (GitHub Copilot): .vscode/mcp.json
{
"servers": { "supero": { "type": "http", "url": "https://api.supero.dev/mcp/v1/messages", "headers": { "X-API-Key": "ak_..." } } } }
Run MCP: List Servers, start supero, and use Copilot in Agent mode.
Anything else. Any client that speaks MCP over streamable HTTP and lets you set a request header will work. More detail, and the one known gap (Claude Desktop's connector screen wants OAuth, which the server does not offer yet), is in docs/connect.md.
Ask your assistant:
Call build_whoami on Supero and tell me what it says.
You should get back your role, your domain and, for a project key, the project it is bound to. If you would rather check from a terminal:
curl -s https://api.supero.dev/mcp/v1/messages \
-H "Content-Type: application/json" \ -H "X-API-Key: ak_..." \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"build_whoami","arguments":{}}}'
Paste this, with your own description in the middle.
With a project key (the project already exists):
Connect to Supero over MCP and use your build_ tools. Everything runs through MCP: don't look for a local supero CLI or a SKILLS.md file on disk, there isn't one.
Build this app in my project: [describe your app: the main thing users do, the key screens, and an admin view].
Work in this order: build_whoami, then build_get_skills to load the spec, then build_plan. Echo the plan back to me and wait for my go-ahead. Then build_get_examples with the closest archetype as your reference, author the bundle, run build_validate and fix everything it reports, run build_doctor and fix its warnings, then build_publish and deploy (build_deploy for a ~30-minute preview, build_go_live for the permanent URL). Finally build_smoke_test the deployed URL and finish with a short summary: what you built, the URL, and how I log in.
With a domain key, change the second paragraph to:
Create a new project with build_create_project (pick a short name and namespace), then build this app in it: [describe your app].
Stuck for an idea? Every project brief ends with a prompt that is ready to paste.
If the assistant starts searching your disk for a CLI, send it this:
Stop reading the local filesystem. There is no CLI and no SKILLS.md. Call build_get_skills over MCP now, author the bundle, then build_validate.
More prompts, for changing an app, fixing a failed deploy and going live, are in docs/prompts.md.
| Step | Tools | What happens |
|---|---|---|
| 1. Orient | build_whoami | Finds out which project it may build into and what the key allows. |
| 2. Learn | build_get_skills, build_get_examples, build_get_service_contract | Reads the build spec, a working reference app, and the contract of each platform service it plans to use. The spec is served live, so it is never out of date. |
| 3. Plan | build_plan | Turns your description into records, roles and screens. You read it and say go. |
| 4. Write | (your assistant) | Writes a small bundle: the data model, the configuration, the setup and the front end. |
| 5. Check | build_validate, build_doctor | The platform checks the bundle and reports what to fix before anything is deployed. |
| 6. Ship | build_publish, build_deploy or build_go_live, build_deploy_status, build_smoke_test | Publishes a version, deploys it, waits for it to come up, and tests the live URL. |
A deploy usually takes a few minutes and can sit in launching for five or more. That is normal: the assistant should keep polling build_deploy_status for up to ten minutes before deciding something is wrong.
The full walk-through is in docs/build-flow.md, and every tool is listed in docs/tools.md (64 tools; you can list them without a key).
What you do not have to build. Sign-in, roles and permissions, per-record and per-field access rules, the database, the REST API, the admin panel, and data kept apart between organisations in a multi-tenant app. There are also ready-made services to switch on instead of writing: bookings, appointments, rentals, cart, orders, payments, approvals, tasks, tickets, reviews, memberships, recurring plans, inventory, document signature, attachments, notifications, email and more. Ask the assistant to call build_list_capabilities to see them all.
build_get_bundle, edits it, then validates, publishes and deploys again. The version number goes up each time.build_deploy gives a preview URL that lasts about 30 minutes, which is enough to click through and share. build_go_live gives a permanent address on supero.live and needs a paid plan.| Free | |
|---|---|
| Price | $0, no card |
| Projects | 3 |
| Preview deployments | 10 per project, about 30 minutes each |
| Schemas | 20 |
| API requests | 10,000 a month |
| Permanent live URL | From the Basic plan |
These are the figures on the pricing page on 5 October 2026. That page is the authority if they differ. A plan and a validation pass cost nothing, so get build_validate clean before spending a preview. More in docs/limits.md.
| You see | It means | Do this |
|---|---|---|
Authentication required | No key reached the server | Check the header is X-API-Key and the client was restarted after you added it. |
401 or Invalid API key | The key is wrong, cut short, revoked, or has Bearer in front | Paste the raw ak_... value. If it is lost, rotate it under API Keys. |
| The assistant cannot create a project | You gave it a project key | Create the project in the dashboard, or use a domain key. |
The assistant looks for a CLI or a SKILLS.md file | It is guessing from old habits | Send the recovery prompt from step 4. |
build_validate fails | The bundle breaks a rule | Let the assistant fix what it lists and run it again. This step is free. |
build_doctor warns that workflows "usually need elevated permission" | That warning is out of date | Ignore it. Workflows register and run with a project key (checked 6 October 2026). |
| The app deployed but screens are half empty | Some starter data may not have been created. This was a platform fault, fixed on 5 October 2026 | If you still see it, ask the assistant to call build_logs and look for SEED FAILURES, deploy again, and please open an issue. |
Deploy stays in launching | The app is still starting | Wait. Poll for up to ten minutes. |
| A status field will not save for ordinary users | Fields named status or state are protected | Name lifecycle fields _state, for example booking_state. |
| Out of previews | The free plan has ten | Validate more before deploying, or upgrade. |
Still stuck? Ask in Discussions. Found a way to make the server misbehave? See SECURITY.md and report it privately.
There are four ways in, and none of them needs permission first. The open issues list good first ones, and we reply within a day.
CONTRIBUTING.md has the details.
ตัดมาแค่ช่วงต้น อ่านต่อใน repo