Cursor MCP setup for shipping Next.js work

Cursor’s marketplace and docs can make MCP look like a collectible. You open settings, see a long list of servers, and toggling everything on feels productive. I ship Next.js client work in Cursor every week, so the useful question is which few tools help me finish this PR without a noisy sidebar.

Cursor MCP lets the agent use external tools while you work in the editor. For shipping, enable a few servers that help a real repo, verify each one, and skip marketplace pile-ons. More servers does not mean more progress.

This page is the shipping version of MCP setup: keep vs collect, a small starting set by pattern (not a ranked vendor must-install list), how to wire one then expand, what matters on Next.js client work, and what I skip on purpose. If you want the broader production loop around Chat, Composer, and review, I already wrote that in How to use Cursor AI to ship faster without wrecking the codebase.

What MCP does in Cursor

MCP (Model Context Protocol) is how Cursor connects the agent to external tools. Without it, the model mostly sees your open files, rules, and chat context. With it, the agent can call tools you have enabled: search, docs, project systems, browsers, and other helpers outside the editor.

That sounds powerful because it is, and it is also easy to over-enable.

When a server is on, the agent can propose tool calls. Those calls cost attention. They can pull in context you did not ask for. They can fail loudly mid-flow. They can tempt you into “while we are here, also check X” loops that never become a clean commit.

I treat MCP like dependencies in package.json. Every entry should earn its place on this repo, this week. If I cannot say what job it does during a normal shipping day, it stays off.

MCP does not replace project rules, tests, or PR review. It runs alongside them. If your rules and workflow are messy, more servers will not fix that. Clean the loop first, then add tools that support the loop.

Keep vs collect

Docs list every server. Collectors enable them all. Shippers keep a short list.

I use a simple keep test before I leave a server enabled:

1. Does this help a real PR this week? Not “might be cool someday.”
2. Can I verify it in under ten minutes? Auth works, a sample call returns something useful, and I know what failure looks like.
3. Does the agent know when to call it? If every prompt triggers noise, the server is too broad or my brief is too vague.
4. Would I miss it tomorrow if I turned it off? If no, turn it off.

Collect mode looks like this: twenty servers enabled, three of them half-authenticated, and the agent spending half a turn deciding which tool to try. Keep mode looks like this: three to five servers, each with a clear job, each verified after a Cursor update.

I also separate “research day” tools from “finish the PR” tools. A docs browser or web search can be useful when you are choosing an approach. During implementation, I often want repo-local truth: the current route, the existing form pattern, the test command that already passes. Extra outbound tools can pull the agent away from the files that matter.

If you are building a personal lab, collect away. If you are finishing client work, keep the set small and boring.

A small starting set (pattern classes only)

I will not give you a ranked “must install these five vendors” list. Vendors change. Auth flows change. What matters is the pattern class and the job it does on a shipping day.

Here are the classes I actually consider for Next.js client work:

1. Repo and project truth

Tools that read or search the systems that already own the work: issue tracker, docs in the company wiki, design notes, or a project board. The goal is fewer tab switches and fewer “wait, what did the ticket say?” moments.

Keep these only if you already use that system day to day. Do not add a board integration for a repo that still runs on Slack threads and a Notion page nobody updates.

2. Docs and API reference

A docs or search helper that can pull current library docs when the model’s training cutoff is the wrong year. Useful for framework APIs, auth libraries, and payment SDKs. Less useful for your own app code. Your app code is in the repo.

3. Browser or preview helpers

Tools that help inspect a running local app, capture a page state, or check a UI path you just changed. Helpful for client-facing Next.js work when the bug is visual or interaction-shaped. Not a replacement for your own click-through.

4. Deployment and observability (optional, later)

Status, logs, or deploy helpers can be useful once the shipping loop is stable. I do not put these in the day-one set. They are high-blast-radius if the agent starts “helpfully” poking production.

5. Domain-specific tools you already trust

Email, Drive, CRM, or CMS adapters only if that product is part of the ticket. A Gmail tool on a pure UI ticket is clutter.

Start with one class that matches this week’s work. Add a second class only after the first one is boring and reliable.

I keep my Cursor habits and ambassador notes on /cursor-ambassador. The point of that page matches this one: practical setup, not a trophy shelf of integrations.

Wire one then expand

Do not enable five servers and then debug which one broke the agent. Wire one.

My sequence:

1. Pick one job. Example: “pull the latest ticket acceptance criteria into chat” or “fetch current Next.js docs for this API.”
2. Enable only that server. Leave the rest off.
3. Authenticate and run a boring sample call. Prefer a read-only action first.
4. Write a short note in the project or personal rules: when to use it, when not to use it.
5. Ship one real PR with it in the loop. If it did not help, disable it.
6. Only then add the next server.

Verification checklist I actually use:

• Does the server show as connected after restart?
• Does a deliberate tool call succeed?
• Does an unrelated prompt still stay in the repo instead of fishing for tools?
• Do I know how to revoke auth if the client repo should not keep that connection?

If step three fails, fix that server before you touch another. Half-broken MCP is worse than no MCP. The agent will retry, stall, or invent a workaround that looks like progress and is not.

Expanding is allowed. Expanding without a job description is how you get marketplace pile-ons.

Next.js client work

On Next.js client projects, MCP earns its keep when it shortens the path from ticket to reviewed PR. Typical moments:

• Confirming how an App Router API actually behaves this year, not last year’s blog post.
• Pulling design or acceptance notes into the same chat where you are scoping files.
• Checking a local preview path after a form or navigation change.
• Looking up a library’s current prop names before the agent invents a close-enough version.

Keep the non-MCP basics either way: project rules, a short plan before Composer writes, scoped files, typecheck/lint, and a PR review that assumes the agent is fast and occasionally wrong. If the agent needs six external tools to “understand” your app, your repo context is underfed. Feed the repo first.

For client work, be careful with anything that can touch staging, production, or customer data. Read-only first. Explicit confirmation for writes. No “just sync the CMS” during a UI polish PR.

Skip list

I skip servers that fail the keep test, even when they look popular.

Skip (or disable later) when:

• Auth is fuzzy. You are not sure which account is connected, or the client repo should not inherit your personal tokens.
• The tool duplicates the repo. Searching your own source through an external wrapper when @ file mentions already work is overhead.
• Every prompt becomes a tool safari. The agent calls three tools before reading the open file.
• The output is noisy. Huge dumps that blow the context window and bury the diff.
• You enabled it “for later.” Later rarely comes. Turn it off until a ticket needs it.
• Write access without a reason. Prefer read-only until you have a repeated, reviewed workflow.
• Marketplace curiosity during a deadline. Curiosity belongs on a sandbox repo, not on the client main branch day.

Also skip ranking lists that treat MCP like a starter pack. Your stack, your ticket queue, and your threat model decide the set. A server that shines for content sites may be dead weight on a gated SaaS dashboard.

Already collected a dozen? Disable all, re-enable the two you used this week, leave the rest off for a month. Most people do not miss them.

If you want help turning Cursor into a shipping habit instead of a settings hobby, that is the Level-up lane I run as Vibe Code Friend. We tighten MCP, rules, and review loops on your real repo so the agent stays useful when the PR still has to land.