Last Updated: 2026-05-25
Purpose: Guide for using MCP (Model Context Protocol) servers in this project
See: Root AGENTS.md for quick reference (current version: docs/VERSIONS.md).
Cursor MCP Governance (Local + Cloud)
Security Baseline (REQUIRED)
- Never commit plaintext secrets in MCP configs.
- Use environment interpolation for credentials (for example:
${env:STITCH_API_KEY}). - Prefer
.cursor/mcp.json.exampleas the shared template and keep machine/user secrets out of source control. - Treat MCP allowlists as convenience, not a security boundary; still enforce command and data review discipline.
Two Config Files Explained
There are two committed MCP config sources in this repository:.cursor/mcp.json.example— Cursor IDE team template. Developers copy/merge this into local.cursor/mcp.json..mcp.json— Claude Code MCP configuration for this repo.
Approved Repo MCP Servers
Repo-shared template servers live in.cursor/mcp.json.example. Team members copy this into local .cursor/mcp.json and merge any personal entries.
Cloud Compatibility Notes
- Cloud agents run in isolated Linux environments; avoid shell-specific assumptions in MCP setup scripts.
- HTTP and stdio MCP servers are preferred for cloud portability.
- Keep required env vars documented alongside cloud setup docs so cloud runs are reproducible.
encore-api-surfaceis local-only when configured ashttp://localhost:3399/mcp; Cursor Cloud agents cannot reach a developer laptop localhost endpoint.
Encore API Surface MCP (encore-api-surface)
Purpose: Enable fast symbol/spec lookups from docs/api/index.json in local Cursor sessions via the custom MCP server.
Team Setup Workflow
-
Confirm index is available:
docs/api/index.jsonis committed; regenerate only if stale or missing: -
Start the local MCP server in a dedicated terminal:
Optional port override:
-
Configure Cursor MCP: copy
.cursor/mcp.json.exampleto.cursor/mcp.json(or merge the new block into your existing local file). - Reload Cursor MCP: restart Cursor or use Cursor Settings -> MCP.
-
Verify tools are visible and callable:
lookup_symbol({ name, limit? })symbols_for_spec({ spec_id })semantic_search({ query, top_k? })(optional)
Semantic Search Prerequisites (Optional)
semantic_search requires both keys to be present in the environment and an embeddings build:
AI_GATEWAY_API_KEYBLOB_READ_WRITE_TOKENnpm run docs:api:embeddings
lookup_symbol and symbols_for_spec.
Limitations and Notes
- Local-only for Cursor IDE: this server URL points to
localhost. - Cursor Cloud should use committed API-surface artifacts (
docs/api/index.json,docs/api/{core}.md) instead of this local MCP endpoint. - v1 is trusted local use only (no auth layer).
- The server hot-reloads when
docs/api/index.jsonchanges.
Troubleshooting
Supabase MCP Usage (REQUIRED)
Purpose: AI agents MUST use Supabase MCP for read operations and documentation lookup. Use Supabase CLI for write operations (migrations, deployments).
When to Use Supabase MCP
ALWAYS use Supabase MCP for:- ✅ Reading project information (project URL, branch list, project details)
- ✅ Searching Supabase documentation (RLS policies, branching, migrations)
- ✅ Querying branch information (list branches, get branch details)
- ✅ Looking up API patterns (best practices, examples)
- ✅ Understanding Supabase features (branching, migrations, RLS)
- ❌ Creating migrations (use CLI:
npx supabase migration neworsupabase migration new) - ❌ Deploying migrations (use CLI:
npx supabase db pushorsupabase db push) - ❌ Generating types (use CLI:
npx supabase gen types typescriptorsupabase gen types typescript) - ❌ Local development (use CLI:
npx supabase startorsupabase start)
When to Use Supabase CLI
ALWAYS use Supabase CLI for:- ✅ Creating migration files (
npx supabase migration neworsupabase migration new) - ✅ Applying migrations (
npx supabase db push,supabase migration up) - ✅ Local development (
npx supabase start,npx supabase db reset, orsupabase start/supabase db resetif on PATH) - ✅ Generating TypeScript types (
npx supabase gen types typescriptorsupabase gen types typescript) - ✅ Linking projects (
npx supabase link --project-reforsupabase link) - ✅ Managing branches (
npx supabase --experimental branches createorsupabase branches create)
supabase start or supabase db reset, remind the user the Supabase CLI must be installed and on PATH; if the user does not have the CLI on PATH, they can run npx supabase start and npx supabase db reset from the project root instead of installing globally.
Testing migrations locally (before committing)
Prerequisite: Supabase CLI available (install and add to PATH, or usenpx supabase from project root). The CLI is not bundled with the repo.
Before committing new or changed migrations:
- Start local stack (if not running):
npx supabase start(orsupabase startif CLI on PATH) - Apply all migrations to local DB:
npx supabase db reset(orsupabase db resetif on PATH; orsupabase migration upfor pending only) - Run project validation:
validate-migration --latest(ornpx tsx scripts/database/validate-migration.ts --latest) - Run RLS tests as needed:
npm run test:rls(or Cursor commandtest-rls) - Then commit and push. Use
npx supabase db push(orsupabase db push) only when targeting a linked remote (staging/production).
Supabase MCP / CLI Operation Matrix
Supabase MCP Read Operations
Use Supabase MCP for read/discovery tasks such as:- Listing projects/branches and checking branch state
- Listing tables, migrations, extensions, advisors, and logs
- Retrieving edge function metadata/code for review
- Searching docs for RLS, branching, migration, and API patterns
Common Supabase Workflow
- Use MCP to discover current state and docs patterns.
- Use CLI to create/apply migrations and deploy execution changes.
- Use MCP again to verify resulting project state and advisor outputs.
Branching Workflow
Persistent Branches:- Map to Git branches (e.g.,
stagingbranch →stagingGit branch) - Automatically sync migrations via GitHub integration
- Use for long-lived environments (staging, production)
- Created automatically for PRs (if GitHub integration enabled)
- Short-lived, deleted after PR merge
- Use for testing feature migrations
main→ Production Supabase projectstaging→ Staging persistent branchdevelop→ Development persistent branch (optional)- Feature branches → Preview branches (auto-created)
- Enable in Supabase Dashboard → Settings → Integrations → GitHub
- Maps Git branches to Supabase branches/projects
- Automatic migration deployment on push
- Preview branches created for PRs
Data Isolation & Key Configuration (CRITICAL)
Understanding Supabase Branching:
Key Points:
- ✅ Same Supabase URL for staging and production is CORRECT (using branching, not separate projects)
- ✅ Different anon keys per branch is REQUIRED (verify in dashboard)
- ✅ Data stays isolated - seed data in staging never appears in production
- ✅ Only migrations merge when PR is merged to main
- The one-time Lovable->Supabase migration completed in 2026-01; its test plan and checklist are archived at
docs/archive/migration-2026-01/PRE_MIGRATION_TEST_PLAN.mdanddocs/archive/migration-2026-01/PRE_MIGRATION_CHECKLIST.md. - For the current prod-promotion workflow, see
docs/runbooks/PROD_MIGRATION_PROMOTION.md.
docs/database/migration-workflow.md and docs/integrations/SUPABASE_SETUP.md for branching configuration. The original branching setup playbook is archived at docs/archive/migration-2026-01/COMPLETION_PLAN.md.
Fallow MCP Usage (OPTIONAL — Codebase Analysis)
Purpose: Fallow MCP exposes structured codebase analysis (dead code, duplication, complexity, boundaries) without manually parsing CLI output. Config file:.cursor/mcp.json— thefallowserver is already configured. Restart Cursor after any MCP config change.
Tools Available
When to Use Fallow MCP
Use Fallow MCP when:- ✅ Running the dead-code-auditor agent to identify orphans and unused exports
- ✅ Proposing file deletions — run analysis first to confirm the file is genuinely unused
- ✅ Reviewing a module for cleanup (replaces manual graph inspection)
- ✅ Checking complexity and duplication before or after refactors
- ✅ Running in CI:
npm run deadcode:ci - ✅ Generating full dead-code audits:
npm run audit:unused-files - ✅ Running local checks:
npm run deadcode,npm run check:dupes,npm run check:health
Current Project Configuration
Fallow is configured in.fallowrc.json:
- Entry points:
src/routes/**/*.tsx,supabase/functions/*/index.ts,scripts/**/*.ts - Ignored files: Barrel indexes (
src/cores/*/index.ts,src/platform/**/index.ts), docs workspace, test fixtures,supabase/functions/_shared - Architecture boundaries: Zones for
platform,cores,shared, androutes
CI Behavior
The dead-code check is currently informational (step still runs withcontinue-on-error). Tighten the gate after baseline cleanup if the team wants dead-code findings to block builds.
Related Commands and Agents
Context7 MCP Usage (REQUIRED)
Purpose: AI agents MUST use the Context7 MCP server to fetch up-to-date library documentation instead of relying on potentially outdated training data. This ensures accurate API usage for all project dependencies. Reference: See Context7 Documentation and Context7 Tips for best practices.Configuration note: Context7 is typically provided by the Cursor plugin MCP environment, not by committed
.cursor/mcp.json.example or root .mcp.json in this repo. If unavailable, use the plugin-managed Context7 server configured in your IDE.
When to Use Context7
ALWAYS use Context7 when:- ✅ Working with any project dependency (React, Supabase, TanStack Query, etc.)
- ✅ Implementing features using third-party library APIs
- ✅ Debugging issues related to library behavior
- ✅ Unsure about correct API usage, parameters, or return types
- ✅ Library version matters (this project uses specific versions - see
package.json)
- ❌ Library APIs that may have changed between versions
- ❌ Deprecated methods or patterns
- ❌ New features in recent library releases
Project Dependencies (Use Context7 For)
The following key libraries are used in this project. Always fetch Context7 documentation before using their APIs:Context7 Best Practices
1. Resolve Library ID First:- Check
AGENTS.mdfor project-specific patterns (e.g.,staleTime/gcTimerequirements) - Review existing code in
src/for established conventions - Ensure compatibility with project architecture
Context7 Workflow
Step 1: Identify the library you need documentation for Step 2: Resolve the library ID using Context7’s resolve function Step 3: Fetch documentation with specific topic focus and version Step 4: Cross-reference with project patterns in this document Step 5: Implement following both library best practices AND project conventionsExample: TanStack Query Usage
Anti-Patterns
- ❌ Assuming API stability - Always verify with Context7 for version-specific APIs
- ❌ Using deprecated patterns - Context7 shows current recommended patterns
- ❌ Ignoring breaking changes - v5 TanStack Query differs significantly from v4
- ❌ Guessing parameter names - Fetch docs to confirm exact API signatures
See Also
- Root AGENTS.md:
AGENTS.md(current: docs/VERSIONS.md) - Quick reference - Context7 Docs: https://context7.com/docs
- Supabase Branching:
docs/database/migration-workflow.md(live); original playbook archived atdocs/archive/migration-2026-01/COMPLETION_PLAN.md - Fallow Docs: https://docs.fallow.tools
- Fallow VS Code Extension: https://marketplace.visualstudio.com/items?itemName=fallow-rs.fallow-vscode
Last Updated: 2026-05-25