Advanced Cursor techniques: tips 91-105

Advanced Cursor techniques connect Cursor’s agent to real systems through MCP servers, hand long tasks to Cloud Agents, and make every change prove itself before a person reviews it. The 15 tips here combine MCP, Cloud Agents, hooks, skills, Bugbot and model discipline into one loop in which tests and gates, not a line-by-line read, decide whether work is done.

This page is for the developer who already uses agent mode, project rules and scoped context every day. You have connected a few MCP servers and started a Cloud Agent or two. The output still lands on your desk as a diff you feel obliged to read in full, because nothing in the setup proves the agent finished the job. These tips fix that.

What you get from tips 91-105

• A committed .cursor/mcp.json that gives the agent read access to GitHub and your development database, with write access added only where you mean it.
• Two copy-paste prompts that turn a ticket or a schema into acceptance tests before any code is written.
• A Cloud Agent task spec whose pull request carries its own evidence.
• A stop hook that runs your type check, lint and tests every time the agent says it is done, and sends it back when they fail.
• A review order (self-review, Bugbot, CI, human sign-off) in which each layer checks something the others cannot.
• A rule for choosing models and a way to see what each task costs.

How the Cursor facts on this page were checked

Feature names (Cloud Agents, Automations, Plan Mode, Worktrees, Rules, Agent Skills, Hooks, Plugins, MCP and Bugbot) were read on cursor.com’s docs on 2026-08-28. On 2026-09-26 cursor.com was unreachable from the writing environment. Hook behaviour was checked instead in the agent code of Cursor’s own @cursor/sdk 1.0.32 package, and MCP server details in each vendor’s README or registry entry.

How should you connect Cursor’s agent to your systems with MCP?

An MCP server gives the agent tools beyond the file system and the terminal: reading a pull request, querying a schema or fetching a ticket. Each server is also code that runs with your credentials, and each one adds tool descriptions to every request. For the basics, see MCP setup in Cursor.

Tip 91: Start every MCP server read-only

Give the agent read access first and add write access per task, not per habit. A read-only server can still leak data into a prompt, but it cannot close a ticket, merge a pull request or drop a table because a prompt injection in an issue body told it to. Approve each server’s tools deliberately, and keep only the servers the current task needs switched on. Reducing MCP token cost shows how to measure what each one costs in context.

Tip 92: Commit one shared .cursor/mcp.json

Commit the server list so every clone gets the same tools, and keep each credential in the developer’s own environment:

.cursor/mcp.json

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/readonly",
      "headers": { "Authorization": "Bearer ${env:GITHUB_PAT}" }
    },
    "postgres": {
      "command": "uvx",
      "args": ["postgres-mcp", "--access-mode=restricted"],
      "env": { "DATABASE_URI": "${env:DEV_DATABASE_URI}" }
    }
  }
}

• GitHub is GitHub’s hosted server from github/github-mcp-server. The /readonly endpoint exposes only read tools. Switch to https://api.githubcopilot.com/mcp/ in a personal config when you want the agent to comment or push.
• Postgres MCP Pro is the PyPI package postgres-mcp (0.3.0, checked 2026-09-26), run with uvx. --access-mode=restricted runs read-only transactions with time limits. Do not run npx postgres-mcp: the npm package of that name is unrelated.
• ${env:NAME} reads the token from the developer’s environment. Point DEV_DATABASE_URI at a local or disposable database, never production.

The older @modelcontextprotocol/server-github and @modelcontextprotocol/server-postgres packages are archived; replace any entry that still uses them. See the GitHub MCP server and database MCP servers for the full options.

Tip 93: Write the migration from the real schema, then prove it

Without a database server, the agent writes a migration against the schema it imagines from your ORM files. With one, it reads the real table first. The proof is not the migration file; it is a clean apply and a schema diff on a database you can throw away.

Copy-paste prompt: schema-aware migration with proof

Use the postgres MCP server to read the current definition of the "users"
and "organizations" tables, including indexes and foreign keys. Do not write
to the database through MCP.

Then write a Drizzle migration that adds users.organization_id as a nullable
foreign key to organizations.id, with an index. Existing rows keep NULL.

Prove it before you stop:
1. Run the migration against the dev database with our migrate script.
2. Read the "users" table again through MCP and show the before/after diff.
3. Run the migration's down step, confirm the schema matches the original,
   then apply it again.
4. Run the repository and service tests that touch users.

Finish with a table: step, command, result. Stop and ask if any step fails.

Tip 94: Turn the ticket into tests before the agent writes code

The issue tracker already holds the acceptance criteria, so let the agent read them rather than paraphrasing them yourself. Linear (https://mcp.linear.app/mcp) and Atlassian (https://mcp.atlassian.com/v2/mcp, which replaces the older /v1 endpoints) both run hosted servers with OAuth; see project management MCP servers. For UI work, Figma’s MCP server gives exact spacing and tokens instead of a screenshot guess.

Copy-paste prompt: ticket to failing tests first

Read Linear issue ENG-482 through the linear MCP server, including comments.

1. List every acceptance criterion as a numbered, testable statement. If a
   criterion is ambiguous, write the question instead of guessing.
2. For each criterion, write one test in the existing test suite that fails
   today. Name each test after its criterion number.
3. Run the tests and show that each new test fails for the expected reason.

Stop there. Do not implement the feature yet. I will review the criteria
and tests, then ask you to make them pass.

Reviewing 10 test names against 10 criteria takes minutes. Reviewing the implementation that makes them pass is the part you no longer need to do line by line.

How do you hand long work to Cloud Agents?

Cursor’s Cloud Agents (the former background agents) “run in isolated VMs in the cloud with full development environments”, and Automations start them on a schedule or on events from source control, Slack, webhooks, Linear, Sentry and PagerDuty (cursor.com docs, checked 2026-08-28). The mechanics are on Cloud Agents and Automations; these tips cover which work to send there and how to get it back in a verifiable state.

Tip 95: Send work that has an oracle

A Cloud Agent cannot ask you a question halfway through, so send it work whose result a machine can judge:

Good Cloud Agent task	Keep it local
Raise coverage on a module, judged by the coverage report	A design decision with no agreed answer
A bug with a failing reproduction test	A bug nobody can reproduce yet
A dependency bump, judged by the full test suite	Work that needs production credentials
A mechanical refactor with a lint rule that detects the old pattern	Changes to auth, payments or migrations without a named reviewer

Tip 96: Write the task as a spec that ends in evidence

Put the acceptance criteria, the patterns to follow, the commands that prove success and the shape of the pull request description in the prompt. The pull request description then carries the evidence, so review starts from results instead of the diff.

Copy-paste prompt: Cloud Agent task with its own evidence

Branch from main. Add Vitest tests for every exported function in
src/services/payment.ts.

Constraints:
- Follow the structure of src/services/__tests__/user.test.ts.
- Mock the Stripe SDK and the database layer; no network calls.
- Cover, per function: a valid call, invalid input, and a failure from each
  dependency (Stripe error, database error).
- Do not change any file under src/ except to fix a bug a test exposes.
  If you find one, stop after writing the failing test and describe it.

Definition of done:
- `npm run typecheck`, `npm run lint` and `npm test` pass.
- Line coverage for src/services/payment.ts is at least 90%.

Open a pull request titled "test: payment service coverage". In the
description, include: the list of test names grouped by function, the
coverage figure before and after, the exact commands you ran with their
final lines of output, and anything you could not test and why.

Tip 97: Trigger routine work from events, not from memory

Once a task spec works by hand, stop starting it by hand. An Automation on a source control, Linear or Slack event runs the same spec every time. Start with one read-mostly job, such as a nightly dependency audit that opens a pull request only when the full test suite passes. Keep permissions narrow: an unattended agent should run under the posture described in permissions, sandboxes and approval modes. To launch runs from your own scripts or CI, use the Cursor SDK and Cloud Agents API. Background and cloud agents compared sets Cursor’s option against Claude Code’s and Codex’s.

How do you make Cursor’s agent prove its work?

The tips so far make the agent reach further. These tips make the result checkable without a human reading every line.

Tip 98: Add a stop hook that runs your gates

Cursor’s hooks are scripts that “run before or after defined stages of the agent loop and can observe, block, or modify behavior” (cursor.com docs, checked 2026-08-28). The stop hook fires when the agent finishes a turn. In Cursor’s agent code (@cursor/sdk 1.0.32, checked 2026-09-26), it receives JSON on stdin with the turn’s status and a loop_count. When it prints a followup_message, the agent continues with that message as its next instruction. The per-hook loop_limit caps how many times that can happen; without one, the runtime stops after five.

.cursor/hooks.json

{
  "version": 1,
  "hooks": {
    "stop": [
      { "command": "node .cursor/hooks/verify-on-stop.mjs", "timeout": 600, "loop_limit": 3 }
    ]
  }
}

.cursor/hooks/verify-on-stop.mjs

// Runs the project's gates when the agent says it is done.
// On failure, sends the agent back with the tail of the output.
import { execSync } from 'node:child_process';
import { readFileSync } from 'node:fs';

const input = JSON.parse(readFileSync(0, 'utf8') || '{}');
const done = (out = {}) => { process.stdout.write(JSON.stringify(out)); process.exit(0); };

if (input.status !== 'completed') done();
// Nothing changed (tracked or untracked): nothing to verify.
if (execSync('git status --porcelain', { encoding: 'utf8' }).trim() === '') done();

const gates = ['npm run typecheck', 'npm run lint', 'npm test'];
for (const cmd of gates) {
  try {
    execSync(cmd, { stdio: 'pipe', encoding: 'utf8' });
  } catch (err) {
    const tail = `${err.stdout ?? ''}${err.stderr ?? ''}`.slice(-3000);
    done({
      followup_message:
        `"${cmd}" failed after your change. Fix the cause in the source code. ` +
        `Do not delete, skip or weaken tests. Output:\n${tail}`,
    });
  }
}
done();

The git status --porcelain check skips the gates when the working tree is clean. Once the tree is dirty, every completed turn runs them, including a turn that only answered a question, so keep the gates fast or compare against a stored hash of git diff to run them only when the diff changed. If your full test suite takes minutes, run the affected tests here and leave the full suite to CI. Assign .cursor/hooks.json and .cursor/hooks/ to a code owner, because anyone who can edit the hook can switch the gate off. Privacy and security in Cursor covers the beforeShellExecution guard that pairs with this hook.

Tip 99: Package the pre-PR routine as a skill

A checklist in a Slack message drifts; a skill in the repository does not. An Agent Skill is a folder with a SKILL.md file, and Cursor’s docs list .cursor/skills/ among project skill locations (read on cursor.com/docs/skills on 2026-08-28, not re-fetched since). The same format works in Claude Code and Codex. Team collaboration in Cursor has a complete pre-pr-check skill to copy. Make its last step write the evidence section of the pull request description, in the format of the evidence bundle, so every pull request looks the same to a reviewer.

Tip 100: Review the diff in a fresh chat, against the rules

The chat that wrote the code shares its blind spots. Open a new chat, point it at the branch, and ask it to find reasons to reject the change.

Copy-paste prompt: adversarial self-review before push

Run `git diff main...HEAD` in the terminal and read the full diff. You did
not write this code. Your job is to find reasons to reject it.

Check, in this order, and cite file:line for each finding:
1. Behaviour the tests do not cover: list each changed branch or error path
   with no test that exercises it.
2. Security: injection, missing authorization checks, secrets, data returned
   to a caller that should not see it.
3. Violations of the rules in .cursor/rules/ that apply to the changed files.
4. Error handling: promises without rejection handling, swallowed errors.

For every finding in 1, write the missing test and run it. Report which new
tests fail. Do not fix the source code; list the fixes you recommend.

The output that matters is the list of new failing tests. Each one is a bug found by execution, not by opinion.

Tip 101: Let Bugbot be a layer, not the gate

Bugbot “reviews pull requests and identifies bugs, security issues, and code quality problems” (cursor.com docs, checked 2026-08-28). Treat its comments as input to the merge decision. The decision itself rests on CI, the evidence in the pull request, and a named human for high-risk paths. Its rules files and Autofix are covered on Bugbot: learned rules and Autofix, together with noise control and a seeded-defect test. Rollouts and PR Routing & Approval covers approving low-risk pull requests by rule.

How do you spend models and tokens deliberately?

Tip 102: Stay on the default model until your evals say otherwise

The rule this site follows for every tool: start on the tool’s default, raise reasoning effort where the model picker offers it, and switch only when your own tests show the other model does better on your tasks. Cursor’s model list and defaults change often and could not be re-verified for this page, so check them in Cursor’s model picker and on the models hub. For a decision framework, see model selection in Cursor. The cheapest evaluation you already own is the stop hook in Tip 98: count how often each model needs a follow-up turn to pass the gates.

Tip 103: Plan in Plan Mode before a long run

Plan Mode “creates detailed implementation plans before writing any code” (cursor.com docs, checked 2026-08-28). Use it before any task that touches more than a handful of files. A wrong plan costs one read; a wrong implementation costs a revert and a second run.

Tip 104: Run two attempts in worktrees and let the tests choose

Worktrees “let Agent work in isolated Git checkouts” (cursor.com docs, checked 2026-08-28). For a task with a strong test oracle, run the same spec in two worktrees, with different models or different approaches, and keep the one that passes the gates with the smaller diff. The tests pick the winner, so you read one diff, not two. The Agents Window shows how to supervise parallel runs.

Tip 105: Measure cost per task, not per month

A monthly usage total tells you that you spent too much, not where. Record tokens per task: one chat per task, a new chat when the task changes, and file references instead of whole directories. Token management in Cursor shows how to read per-run token counts and log every context compaction with a hook.

How do you verify the output without reading every line?

Each technique above adds one check. Together they form the review path for an agent’s change:

1. Before code: the acceptance criteria exist as failing tests (Tip 94), and you have reviewed the test names, not the implementation.
2. Every agent turn: the stop hook runs type check, lint and tests, and sends the agent back until they pass (Tip 98).
3. Before push: a fresh chat turns gaps in coverage into new failing tests (Tip 100), and the pre-PR skill writes the evidence section (Tip 99).
4. On the pull request: CI reruns every gate from the base branch’s configuration, and Bugbot adds judgement on logic and rules (Tip 101).
5. Sign-off: a named owner reads the evidence. They read the code only for high-risk paths such as auth, payments and migrations. Reading evidence instead of code sets out that decision.

What breaks with advanced Cursor setups?

The stop hook loops on the same failure. The agent keeps “fixing” a test it cannot make pass, and the loop ends at the limit with the gates still red. Lower loop_limit to 2 or 3 so a stuck run stops early. Read the last follow-up message: if the failure is an environment problem such as a missing service or a missing env var, fix the environment, not the prompt.

The agent edits a test to get past the hook. The follow-up message forbids it, but instructions are not enforcement. Add a CI step that fails when a pull request deletes or skips a test without a test-change-approved label. Put test directories under CODEOWNERS so a changed assertion needs a human.

An MCP server fails to start. Run the server’s command from the config in your own terminal with the same environment variables. Most failures are an expired token, a variable missing from the shell Cursor started in, or uvx or npx not on the path Cursor sees. For remote servers, sign in again from Cursor’s MCP settings. See MCP connection issues.

A Cloud Agent’s pull request does the wrong thing well. The spec left room for interpretation. Close the pull request, add the missing criterion as a failing test to the spec, and run it again. Do not fix the pull request by hand: the next run of the same spec repeats the mistake.

An unattended agent follows instructions hidden in an issue or web page. Ticket text and fetched pages are untrusted input. Keep Automation agents on read-only MCP servers, give them no production credentials, and require a human merge for anything they open.

Token use jumps after you add servers or rules. Every enabled MCP server and every always-on rule costs context on every request. Switch off the servers the task does not use, scope rules with globs, and compare per-task token counts before and after the change.

Where to go next after tips 91-105

• Previous in the series: large codebase strategies.
• Next in the series: team collaboration in Cursor, which shares these rules, skills and MCP servers across a team.
• Go deeper on unattended work: Cloud Agents and Automations and building your own MCP servers for Cursor.
• Standardise what a pull request must prove: the evidence bundle.