Skip to main content
Version: 1.3.0
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.example as 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.
These files intentionally differ by runtime/tooling focus. Keep secrets in environment variables and local config files, not in git.

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-surface is local-only when configured as http://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

  1. Confirm index is available: docs/api/index.json is committed; regenerate only if stale or missing:
  2. Start the local MCP server in a dedicated terminal:
    Optional port override:
  3. Configure Cursor MCP: copy .cursor/mcp.json.example to .cursor/mcp.json (or merge the new block into your existing local file).
  4. Reload Cursor MCP: restart Cursor or use Cursor Settings -> MCP.
  5. 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_KEY
  • BLOB_READ_WRITE_TOKEN
  • npm run docs:api:embeddings
When these are not configured, the server still supports 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.json changes.

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)
DO NOT use Supabase MCP for:
  • ❌ Creating migrations (use CLI: npx supabase migration new or supabase migration new)
  • ❌ Deploying migrations (use CLI: npx supabase db push or supabase db push)
  • ❌ Generating types (use CLI: npx supabase gen types typescript or supabase gen types typescript)
  • ❌ Local development (use CLI: npx supabase start or supabase start)

When to Use Supabase CLI

ALWAYS use Supabase CLI for:
  • Creating migration files (npx supabase migration new or supabase migration new)
  • Applying migrations (npx supabase db push, supabase migration up)
  • Local development (npx supabase start, npx supabase db reset, or supabase start / supabase db reset if on PATH)
  • Generating TypeScript types (npx supabase gen types typescript or supabase gen types typescript)
  • Linking projects (npx supabase link --project-ref or supabase link)
  • Managing branches (npx supabase --experimental branches create or supabase branches create)
Canonical CLI workflow: See SUPABASE_CLI_LOCAL_WORKFLOW.md for when/how to use the CLI, install/verify steps, and agent rules. For AI agents: If you suggest 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 use npx supabase from project root). The CLI is not bundled with the repo. Before committing new or changed migrations:
  1. Start local stack (if not running): npx supabase start (or supabase start if CLI on PATH)
  2. Apply all migrations to local DB: npx supabase db reset (or supabase db reset if on PATH; or supabase migration up for pending only)
  3. Run project validation: validate-migration --latest (or npx tsx scripts/database/validate-migration.ts --latest)
  4. Run RLS tests as needed: npm run test:rls (or Cursor command test-rls)
  5. Then commit and push. Use npx supabase db push (or supabase db push) only when targeting a linked remote (staging/production).
See: SUPABASE_CLI_LOCAL_WORKFLOW.md (full workflow) and Troubleshooting Guide if you see “Remote migration versions not found in local migrations directory” when pushing to a remote.

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

  1. Use MCP to discover current state and docs patterns.
  2. Use CLI to create/apply migrations and deploy execution changes.
  3. Use MCP again to verify resulting project state and advisor outputs.

Branching Workflow

Persistent Branches:
  • Map to Git branches (e.g., staging branch → staging Git branch)
  • Automatically sync migrations via GitHub integration
  • Use for long-lived environments (staging, production)
Preview Branches:
  • Created automatically for PRs (if GitHub integration enabled)
  • Short-lived, deleted after PR merge
  • Use for testing feature migrations
Branch Naming Convention:
  • main → Production Supabase project
  • staging → Staging persistent branch
  • develop → Development persistent branch (optional)
  • Feature branches → Preview branches (auto-created)
GitHub Integration:
  • 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
Pre-Migration Verification:
  • 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.md and docs/archive/migration-2026-01/PRE_MIGRATION_CHECKLIST.md.
  • For the current prod-promotion workflow, see docs/runbooks/PROD_MIGRATION_PROMOTION.md.
See: the live migration workflow in 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 — the fallow server 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
Use CLI directly when:
  • ✅ 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, and routes

CI Behavior

The dead-code check is currently informational (step still runs with continue-on-error). Tighten the gate after baseline cleanup if the team wants dead-code findings to block builds.

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)
DO NOT rely on training data for:
  • ❌ 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:
2. Be Version-Specific:
3. Use Focused Topics:
4. Verify Against Project Patterns: After fetching Context7 docs, cross-reference with project patterns:
  • Check AGENTS.md for project-specific patterns (e.g., staleTime/gcTime requirements)
  • 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 conventions

Example: 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


Last Updated: 2026-05-25