How to Use MCP Tools With Coding Agents

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

Connect the servers that bring context the agent is missing, not every server available. The biggest gain comes from the systems your team already works in. For a support team, a presenter in Cursor's technical support workshop named three groups: ticketing, the knowledge base and customer context.

An MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server is better when it returns more signal than the raw shell. Mobile builds show the difference. In Cursor's mobile development workshop, the presenter's main reason to use the Xcode MCPAn MCP server Apple maintains inside Xcode that exposes the simulator, build logs and debugging to Cursor, so the agent can run and iterate on iOS apps it writes. Press Enter for the full definition. over terminal build commands was that Xcode's build-time and run-time logs carry more detail than a terminal build returns. The agent works from that extra detail to fix the failure.

Try an API key in mcp.json first. A presenter in Cursor's JetBrains workshop still called that the most reliable first pass, and Cursor's docs say MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers take API keys and tokens through environment variables in that config. Fall back to OAuth when a server requires it.

In the CLI, run agent mcp login <identifier> with the server's name from mcp.json. The CLI handles the callback, and the agent can use the server as soon as login completes. In the editor, adding a server from the Cursor Marketplace installs it and signs you in with OAuth.

Check what it connects to and what permissions it asks for, because that is the part you cannot read for yourself. Most of what a Cursor pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. Press Enter for the full definition. bundles is text you can open before you trust it. An MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server is code that runs and reaches external systems. Cursor manually reviews every Marketplace plugin before listing it, which sets a minimum bar but does not tell you what this server does with your data.

Cursor's MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. docs turn that into two habits: check what data and APIs a server will access, and use restricted API keys with only the permissions it needs. Decide what the agent needs to see, connect that much, and add write access only when a workflow needs it.

Approvals are the second control. MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. tools follow the same Run Modes as terminal commands. Under Auto-review, the default since Cursor 3An older release label for Cursor's multi-agent interface; current product guidance calls the active surface the Agents Window. Press Enter for the full definition..6, allowlisted tools run immediately and other calls go to a classifier before anything reaches you. To approve a server's writes yourself, describe them in permissions.json or switch to Allowlist mode, where anything off your allowlist asks first.

Not much, for the servers that matter most. Look at what the high-value servers are for: logs from Datadog, docs from Notion, the bug report from Linear, and build output from Xcode that is more detailed than what a terminal build returns. Every one of those is a read, so the cautious configuration and the useful one are mostly the same.

Read-only does cost you at the reporting end of a job, such as pushing a migration plan into a Confluence doc and filing the Jira stories that follow from it. Those writes are worth having.

Verify them, though. In one Cursor workshop, the Atlassian MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. hung partway through creating tickets, so confirm the pages and tickets landed instead of taking the agent's word for it.

On a small team, the repo decides. The servers in mcp.json are the list, everyone sees changes to it in a diff, and that is enough.

MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. configuration lives at three scopes. A global ~/.cursor/mcp.json is personal, a project .cursor/mcp.json is shared through the repo, and on Teams and Enterprise plans admins can also share servers through a team marketplace. The personal scope is where servers appear that nobody else knows about.

There is a second reason to keep the list short. Each connected server adds its instructions and tool catalog to the context, and the context ring's breakdown shows them as their own MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. category. Cursor's MCP docs note that turning off a server you don't need reduces tool clutter. We expect a long tool list to make the agent's choices worse as well, but no source we found says where that starts.