Advanced Techniques: Tips 91-105

You have mastered agent mode, your project rules are dialed in, and you handle large codebases without breaking a sweat. But you are still missing the features that transform Cursor from a smart editor into a development platform: MCP servers that connect the AI to your infrastructure, background agents that work while you sleep, and custom automations that eliminate entire categories of repetitive work. These 15 tips are for the developers who want to push every boundary.

What You Will Walk Away With

• MCP server setup that connects Cursor to your database, project management, and CI/CD pipeline
• Background agent workflows for tasks that run asynchronously
• Custom automation patterns that eliminate repetitive development tasks
• The Bug Finder and code review workflows that catch issues before your teammates do
• Strategies for balancing model cost against output quality

MCP Servers: Extending the Agent’s Reach

Tip 91: Understand What MCP Servers Actually Do

Model Context Protocol (MCP) servers give the agent tools beyond reading files and running terminal commands. Without MCP, the agent is limited to what is on your filesystem. With MCP, it can:

• Query your production database directly
• Read and update Jira/Linear tickets
• Fetch designs from Figma
• Check deployment status in your CI/CD pipeline
• Access browser DevTools for debugging

The important mental model: MCP servers are not plugins or extensions. They are tool providers that the AI can invoke during a conversation. The agent decides when to use them based on your prompt, just like it decides when to read a file or run a command.

Tip 92: Set Up Essential MCP Servers

Configure the MCP servers that have the highest impact for most development workflows:

// .cursor/mcp.json (project level)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${DATABASE_URL}" }
    }
  }
}

Enable MCP servers on demand

Each enabled MCP server adds to the context that the agent processes. If you have 10 MCP servers enabled, the agent spends tokens figuring out which tools are available before it even starts your task. Enable only the servers relevant to your current work.

Tip 93: Use Database MCP for Schema-Aware Development

With a PostgreSQL or MySQL MCP server connected, the agent can query your actual database schema instead of guessing:

Copy-paste database-aware prompt

Using the database connection, check the current schema for the “users” table. Then create a new Drizzle ORM migration that adds an “organization_id” column as a foreign key to the “organizations” table, with a default value of null for existing rows.

After creating the migration, verify it by running the migration against the dev database and querying the updated schema.

This eliminates the category of bugs where the agent generates a migration that does not match the actual database state.

Tip 94: Connect Figma MCP for Design-to-Code Workflows

With the Figma MCP server, the agent can pull actual design tokens, component specifications, and layout information from your Figma files:

Look at the "Dashboard" page in our Figma project. Extract the card component design -- its spacing, colors, typography, and layout. Then implement it using our existing Tailwind classes and React component patterns from @src/components/.

This produces significantly better results than pasting a screenshot because the agent gets exact values (padding: 24px, not “some padding”) and color tokens (your design system’s actual hex values, not approximations).

Tip 95: Use Atlassian MCP for Ticket-Driven Development

Connect Jira or Linear to let the agent read tickets and update status:

Copy-paste ticket-driven development prompt

Read the requirements from JIRA ticket PROJ-1234. Implement the feature described in the ticket, following the acceptance criteria. After implementation, update the ticket status to “In Review” and add a comment with a summary of changes.

This closes the loop between project management and development. The agent reads the ticket, implements the feature, and updates the ticket — all in one conversation.

Background Agents

Tip 96: Use Background Agents for Long-Running Tasks

Background agents run in Cursor’s cloud infrastructure. You do not need to keep your editor open. Start a background agent for:

• Generating test coverage across an entire module
• Implementing a feature from a GitHub issue description
• Refactoring a large directory to follow a new pattern
• Creating documentation for an undocumented codebase

The background agent creates a branch and opens a PR when it finishes. You review the PR like any other code change.

Tip 97: Write Clear Specifications for Background Agents

Background agents cannot ask clarifying questions. Your prompt needs to be self-contained:

Copy-paste background agent specification

Branch from main. Create comprehensive vitest tests for every exported function in src/services/payment.ts.

Requirements:

• Test happy paths with realistic data
• Test error cases (network failures, invalid inputs, missing required fields)
• Test edge cases (zero amounts, maximum amounts, concurrent requests)
• Mock external dependencies (Stripe SDK, database queries) using vitest mocks
• Aim for 90% code coverage on the file
• Follow the test patterns established in src/services/tests/user.test.ts

After writing tests, run them to verify they pass. Fix any failures. Open a PR titled “test: add payment service test coverage” with a summary of test cases added.

The more specific the prompt, the better the output. Include the patterns to follow, the tools to use, and the expected output format.

Tip 98: Assign Background Agents from GitHub Issues

When a GitHub issue has clear requirements, assign it directly to a background agent. This works best for:

• Bug fixes with clear reproduction steps
• Small feature additions with well-defined scope
• Documentation updates
• Dependency updates with migration guides

The background agent reads the issue, implements the solution, and opens a PR referencing the issue. Your role shifts from implementer to reviewer.

Custom Automations

Tip 99: Build a “Pre-PR” Automation Prompt File

Save your team’s pre-PR checklist as a prompt file and use it for every PR:

.cursor/prompts/pre-pr.md

# Pre-PR Checklist

Run each step and fix any issues before proceeding to the next:

1. pnpm run typecheck -- fix all TypeScript errors
2. pnpm run lint -- fix all linting issues (do not add eslint-disable comments)
3. pnpm run test -- fix test failures by modifying source code, not test assertions
4. Check for console.log/console.debug statements -- remove any that are not intentional
5. Check for TODO comments that should be addressed in this PR
6. Verify all new files have proper imports and exports
7. Run pnpm run build to verify the production build succeeds

After all steps pass, summarize what was fixed.

Reference it with @.cursor/prompts/pre-pr.md at the end of every development session.

Tip 100: Create a “New Feature” Automation Template

Standardize how new features are scaffolded:

Copy-paste new feature scaffold prompt

Create a new feature module for “notifications” following our established patterns:

1. Create src/services/notification.ts following the pattern in @src/services/user.ts
2. Create src/api/notifications/route.ts following the pattern in @src/api/users/route.ts
3. Create src/types/notification.ts with TypeScript interfaces
4. Create src/services/tests/notification.test.ts with comprehensive tests
5. Add the Drizzle schema to @src/lib/db/schema.ts following existing table patterns
6. Create a database migration for the new table
7. Export everything from the appropriate index files

Run tests after each file creation to ensure nothing breaks.

Tip 101: Automate Log-Based Debugging

Create a reusable prompt for the debugging-with-logs workflow from Tip 69:

.cursor/prompts/debug-with-logs.md

# Debug with Logs

I am debugging an issue in [FILE]. Here is what I expect vs what happens:
- Expected: [DESCRIPTION]
- Actual: [DESCRIPTION]

Step 1: Add detailed console.log statements at every decision point in the file.
Log function entry/exit, all parameter values, intermediate calculation results,
and any conditional branch taken.

Step 2: I will run the scenario and paste the logs back.

Step 3: Analyze the logs, identify where actual behavior diverges from expected,
and propose a targeted fix.

Step 4: Remove all debug logging after the fix is verified.

Code Quality Tools

Tip 102: Use Bug Finder Systematically Before Every PR

Bug Finder (Cmd+Shift+P > “Bug Finder”) compares your branch against main and flags potential issues. Make it part of your workflow:

1. Finish implementing your feature
2. Run your pre-PR checklist (Tip 99)
3. Run Bug Finder
4. Review each flagged issue — fix genuine bugs, dismiss false positives
5. Run tests one more time to verify the fixes
6. Open your PR

Bug Finder catches a specific category of bugs that linters and type checkers miss: logical errors, unhandled edge cases, and inconsistent behavior patterns. It is worth the 30 seconds per PR.

Tip 103: Use Agent Mode for Pre-Merge Code Review

Before requesting a human code review, run an AI review:

Copy-paste self-review prompt

@git diff main

Review all my changes as if you are a senior engineer reviewing this PR. Check for:

1. Security issues (injection, auth bypass, data exposure)
2. Performance concerns (N+1 queries, missing indexes, unnecessary re-renders)
3. Error handling gaps (unhandled promise rejections, missing error cases)
4. Naming and readability issues
5. Missing or incomplete test coverage
6. Violations of the patterns established in @.cursor/rules/

Be critical. I would rather fix issues now than get them flagged in review.

This is not a replacement for human code review. It is a first pass that catches the easy stuff so your human reviewer can focus on architecture and design.

Cost and Model Optimization

Tip 104: Switch Models Based on Task Phase

A single feature goes through multiple phases, each with different model requirements:

Phase	Recommended Model	Why
Planning and architecture	Claude Opus 4.6	Needs deep reasoning about system design
Implementation	Claude Sonnet 4.5	Good enough for writing code, much faster
Debugging	Claude Opus 4.6	Complex reasoning needed for tricky bugs
Test generation	Claude Sonnet 4.5	Pattern-following task, does not need deep reasoning
Code review	Claude Opus 4.6	Needs to reason about edge cases and security
Documentation	Claude Sonnet 4.5	Straightforward generation task

Switch models using the model picker in the agent panel. Most developers default to Opus for everything and burn through their quota. Sonnet handles 70% of development tasks equally well at a fraction of the cost.

Tip 105: Track and Manage Your Token Budget

Cursor provides usage tracking in Settings > Usage. Monitor it to avoid quota surprises:

• Check weekly usage patterns to understand your consumption
• Identify which tasks consume the most tokens (usually long agent conversations with many file references)
• Set a personal budget and switch to Sonnet when you are approaching the limit
• Use Max Mode only when standard context is genuinely insufficient

The developers who run out of quota mid-sprint are usually the ones who use Opus with Max Mode for every task. The ones who never run out are strategic about model selection and context management.

When This Breaks

MCP server fails to connect: Check that the required environment variables are set (GITHUB_TOKEN, DATABASE_URL, etc.). Run the MCP server command manually in your terminal to see error output. Common causes: expired tokens, wrong connection strings, missing npm packages.

Background agent produces low-quality output: The prompt was not specific enough. Background agents need self-contained specifications because they cannot ask clarifying questions. If the output is consistently poor, add more detail to your prompts: specific files to follow as patterns, exact test frameworks to use, and explicit constraints.

Bug Finder reports too many false positives: Bug Finder flags intentional patterns (unused variables in destructuring, deliberate type widening) as potential bugs. Treat it as an advisory tool, not a gate. Fix the genuine issues and skip the false positives.

Token usage is unexpectedly high: Long agent conversations with directory-level @ references are the biggest token consumers. Break conversations into smaller, scoped sessions. Reference specific files instead of entire directories. Start new conversations for new tasks instead of continuing existing ones.

What is Next

These advanced techniques make you individually productive at an exceptional level. The final section, Team Collaboration (Tips 106-112), shows you how to scale these practices across your entire team — shared rules, onboarding workflows, and collaborative patterns that make the whole team faster.