MCP Server Integrations

"Implement @figma/Dashboard/UserCard component
Match exact spacing, colors, typography from design"

AI reads Figma directly, gets pixel-perfect values

You: Need to understand relationships between tables
[Open database tool]
[Run DESCRIBE queries]
[Copy table schemas]
[Switch back to Cursor]
[Paste into chat]
[Repeat for related tables]

"Show me all tables that reference the users table
Explain the relationship structure"

AI queries database directly, sees foreign keys, constraints

[Open Linear]
[Read issue #234]
[Read acceptance criteria]
[Check comments for clarifications]
[Copy requirements]
[Switch to Cursor]
[Paste requirements]
[Start coding]
[Realize you missed a comment]
[Switch back to Linear]
[Repeat]

"Implement @linear/VEL-234"

AI reads:
- Issue description
- Acceptance criteria
- Comments and clarifications
- Linked issues/dependencies

AI suggests approach based on complete context

You: "What's the button padding in the design?"
[Switch to Figma]
[Inspect element]
[Copy values]
[Switch back]
You: "It's 12px vertical, 24px horizontal... wait, which breakpoint?"

You: "Match the button styling from @figma/DesignSystem/Button"
AI: [Reads Figma directly, gets exact values]

You: "Take a screenshot of @localhost:3000/dashboard
      and compare to @figma/Dashboard design"
AI: [Captures screenshot, compares, identifies differences]

1. Open database client (pgAdmin)
2. Run EXPLAIN ANALYZE manually
3. Copy results to text file
4. Research what "Seq Scan" means
5. Identify missing indexes
6. Check if columns are indexed
7. Draft CREATE INDEX statements
8. Test in dev database
9. Measure improvement
10. Document findings

Step 1: Ask AI to analyze query
You: "This query is slow @src/reports/SalesReport.ts line 23

@database analyze the query execution plan
What's causing the slowness?"

AI: [Queries database via MCP]
"Running EXPLAIN ANALYZE...

Issues found:
1. Sequential scan on orders table (2.1M rows)
2. Missing index on orders.created_at
3. Join with products doing nested loop (expensive)
4. No index on orders.product_id

Estimated impact:
- Add index on (created_at, product_id): 80% improvement
- Consider composite index for this query pattern"

Step 2: Generate optimal indexes
You: "Generate the CREATE INDEX statements
Show me before/after explain plans"

AI: [Queries database, generates DDL]
"Recommended indexes:

CREATE INDEX idx_orders_created_at_product
ON orders(created_at, product_id);

CREATE INDEX idx_orders_user_status
ON orders(user_id, status)
WHERE status != 'cancelled';

Before: Seq Scan cost=48234
After (estimated): Index Scan cost=892

Expected improvement: 30s → 0.5s"

Step 3: Verify and test
You: "Check if any similar indexes already exist"

AI: [Queries database]
"Existing indexes on orders:
- idx_orders_user_id (user_id)
- idx_orders_created (created_at) ← This exists!
  But query needs composite index for optimal performance"

Step 4: Generate migration
You: "Generate migration file following @migrations/2024-10-15.sql"

AI: [Creates migration]

You: "I need to add a 'favorites' feature for products
@database show me:
1. Current products table structure
2. How user-product relationships are modeled
3. Suggest schema for favorites"

AI: [Queries database via MCP]
"Current products table:
- id (primary key)
- name, description, price
- category_id (foreign key)
- created_at, updated_at

User-product relationships:
- purchases: orders table (users -> orders -> order_items -> products)
- reviews: product_reviews table (many-to-many via reviews)
- cart: cart_items table (temporary relationship)

Recommended favorites schema:

CREATE TABLE user_favorites (
  user_id INTEGER REFERENCES users(id),
  product_id INTEGER REFERENCES products(id),
  created_at TIMESTAMP DEFAULT NOW(),
  PRIMARY KEY (user_id, product_id)
);

CREATE INDEX idx_user_favorites_user ON user_favorites(user_id);
CREATE INDEX idx_user_favorites_product ON user_favorites(product_id);

This matches your existing pattern for user-product relationships."

You: "Generate the migration and repository code"

AI: [Creates migration + TypeORM repository matching existing patterns]

You: "Implement @linear/VEL-123"
AI: [Reads issue details, acceptance criteria, comments]
AI: "This issue requires adding rate limiting to /api/auth/login..."

1. Open Linear, read issue VEL-456
2. Copy requirements to notes
3. Check comments for clarifications
4. Find related issues mentioned
5. Open those, read context
6. Switch to Cursor
7. Start implementing
8. Realize acceptance criteria unclear
9. Switch back to Linear
10. Read comments again
11. Ask PM for clarification in comment
12. Wait for response
13. Continue implementation

Step 1: Pull full context
You: "Show me @linear/VEL-456 with full details
Include acceptance criteria, comments, and linked issues"

AI: [Reads via MCP]
"Issue VEL-456: User Notification Preferences

Description:
Users need granular control over notification types.
Currently all-or-nothing (all notifications or none).

Acceptance Criteria:
✓ User can toggle email notifications per category
✓ Categories: Orders, Promotions, Account, System
✓ Default: All enabled for new users
✓ Settings page in user profile
✓ Immediate effect (no delay)

Comments (3):
- PM: 'Should apply to existing users with all enabled'
- Designer: 'Figma design ready: [link]'
- Backend Lead: 'Use JSONB column for flexibility'

Linked Issues:
- VEL-455: Email service refactor (dependency - merged)
- VEL-457: Push notifications (future - blocked by this)

Status: Ready for Development
Assigned: You
Sprint: Current"

Step 2: Clarify ambiguities
You: "Based on this issue, clarify:
1. Should we support push notifications now or just email?
2. What happens to existing notification preferences?"

AI: [Analyzes issue context]
"Based on comments and linked issues:
1. Email only for now. VEL-457 will add push later.
2. Existing users: Default all categories enabled (per PM comment)
   Migration needed to set defaults."

Step 3: Plan implementation
You: "Create implementation plan
Check @src/users/ for existing preference patterns"

AI: [Combines Linear context + codebase]
"Implementation Plan:

1. Database:
   - Add preferences JSONB column to users table
   - Migration with default: {email: {orders: true, ...}}

2. Backend:
   - PreferenceService (CRUD for preferences)
   - Update NotificationService to check preferences
   - API endpoints: GET/PUT /api/users/me/preferences

3. Frontend:
   - Settings page component
   - Toggle UI for each category
   - Immediate save on toggle

4. Tests:
   - Unit: PreferenceService
   - Integration: API endpoints
   - E2E: Toggle preferences, verify emails

Estimated: 6-8 hours

Matches existing pattern in @src/users/UserSettings.ts"

Step 4: Implement with context
You: "Implement step 1 (database)
Follow patterns from @migrations/
Use JSONB as suggested in issue"

AI: [Generates migration with proper defaults]

Step 5: Update issue as you progress
You: "Add comment to @linear/VEL-456:
'Database migration complete. Starting backend implementation.'"

AI: [Posts comment via MCP]
"Comment added to VEL-456. Team can see progress."

Figma MCP:
- 15 design references per day
- 3 minutes saved per reference
- 45 min/day saved
- 3.75 hours/week saved
- Setup time: 30 minutes

ROI: Pays back in 1 day ✅

## Database MCP: Non-negotiable

- [ ] Read-only user only (GRANT SELECT, no INSERT/UPDATE/DELETE)
- [ ] Development or staging database only (NEVER production)
- [ ] Connection via .env that's in .cursorignore
- [ ] No tables with PII/sensitive data (or mask them)
- [ ] Review what AI queries (can expose data in logs)

-- Create read-only user for MCP
CREATE USER cursor_mcp WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp_development TO cursor_mcp;
GRANT USAGE ON SCHEMA public TO cursor_mcp;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO cursor_mcp;

-- Verify (should show only SELECT)
SELECT * FROM information_schema.role_table_grants
WHERE grantee = 'cursor_mcp';

Setting up Database MCP to read schema that hasn't changed in 6 months

# docs/database-schema.md
Just document the schema once, reference with @docs

Good: "Here's my code @src/feature.ts and design @figma/Feature"
Bad:  "@database get schema, @github get issue, @figma get design..."

❌ Connecting MCP to production database "for debugging"

## Before Installing MCP Server

- [ ] Clear use case (what pain does this solve?)
- [ ] Team will use it regularly (not just you)
- [ ] Security reviewed (what data gets exposed?)
- [ ] Credentials in .env and .cursorignore
- [ ] Read-only access where applicable
- [ ] Documented in project README
- [ ] Team trained on when to use it

## After Installing

- [ ] Test with example query
- [ ] Verify AI can access data
- [ ] Confirm security constraints work
- [ ] Document common patterns for team
- [ ] Review after 2 weeks: still providing value?