Every app is an MCP server

An MVP in 2026 has two audiences: people using the UI, and AI assistants acting on the user's behalf. geenius-mvp treats the second as a first-class surface. Add mcp to your feature list and the scaffolded app becomes its own Model Context Protocol server — every table gets MCP tools, and both Convex and Supabase variants speak the same protocol.

Tools over your tables

On Convex, JSON-RPC is mounted at your Convex site URL under /mcp, backed by a ported MCP kit and headless internal functions. On Supabase, the identical protocol is served from an Edge Function using verify_api_key and the service role — deploy functions/mcp with --no-verify-jwt and an APP_URL secret. An optional in-app MCP page shows the endpoint, a copyable .mcp.json, and a live tool list. The protocol was verified live: initialize, tools/list, and a 401 on any unauthenticated call.

OAuth 2.1, so chat apps just connect

API keys are fine for dev tools, but chat clients like Claude expect to connect by pasting an endpoint and clicking through an auth flow. So every scaffolded app ships a full authorization server:

• RFC 9728 protected-resource metadata and RFC 8414 discovery
• RFC 7591 dynamic client registration — no manual client setup
• PKCE with S256, single-use hashed authorization codes, rotating refresh tokens
• An in-app consent page, and loopback redirect matching for Claude Code
• Hybrid auth: OAuth bearer tokens and API keys resolve to the same principal

The Supabase variant serves discovery from the Edge Function via the 401 resource_metadata pointer — the pattern Claude's own docs bless for Supabase. The entire chain was live-verified end to end: discovery, dynamic registration, the authorize redirect, the PKCE code exchange, an OAuth-authenticated tools/call, refresh-token rotation, and rejection of a replayed code.

In practice this means a user of your MVP opens their chat app, adds your endpoint as a connector, approves the consent screen, and their assistant can now read and write their data — scoped to them, because both auth paths resolve to a real user.

Interactive UI resources

Text-only tool results are a ceiling. The mcp feature also implements MCP Apps (SEP-1865): the server declares ui:// templates with the text/html profile, serves them through resources/read, and links tools to them via _meta.ui. Tool responses can carry structuredContent plus embedded live HTML, compatible with mcp-ui hosts. The scaffold includes an items-dashboard example, so a chat client that supports MCP Apps renders an actual interactive dashboard inside the conversation instead of a wall of JSON.

One flag

pnpm new my-idea --type webapp --features example,mcp --json
# mcp implies api-keys automatically — keys are how dev tools authenticate

That is the entire setup. The feature manifest encodes the dependency (mcp implies api-keys), the scaffolder strips or keeps the marker blocks, and the deploy script puts the endpoint on the public internet. Your MVP is a product for humans and a tool server for their agents, from the first deploy.