What MCP Enables Cursor to Do: Tools, Context, and Automation

Model Context Protocol (MCP) lets Cursor connect to external tools and data sources. In practice, Cursor is the client, an MCP server exposes capabilities, and Cursor Agent can discover and invoke those capabilities when they fit your prompt. An integration may provide context, perform actions, or do both, depending on the server implementation.

This guide explains the architecture, setup options, approval controls, practical workflows, failure modes, and operating considerations so you can decide where MCP belongs in a Cursor project.

1. What MCP adds to Cursor

Without MCP, Cursor mainly works with the code and context available in the editor. With MCP, you can connect Agent to systems outside the repository, such as internal documentation, project-management data, or an automation service. Cursor’s documentation describes MCP as connecting Cursor to external tools and data sources.

• Tools: callable operations exposed by an MCP server. Agent can discover them and request a tool call when the prompt needs it.
• Context: information retrieved from an external source, such as documentation or project records.
• Actions: operations that change something in another system, such as creating or updating a project item.
• Automation: a repeatable chain in which Agent gathers context, calls one or more tools, and reports the result in chat.

MCP does not automatically grant access to a service. You still need a suitable server, configuration, and any credentials or OAuth authorization that server requires.

2. The request flow

1. You configure an MCP server in Cursor.
2. Cursor starts a local server over stdio or connects to a remote endpoint using a supported remote transport such as SSE or Streamable HTTP.
3. The server advertises its available tools and, where supported, access to external data.
4. Agent considers those capabilities alongside your prompt and enabled tools.
5. Cursor asks for approval by default before an MCP tool runs.
6. The tool result is returned to Agent and shown in the conversation, where it can inform the next step.

The model does not call every available tool on every prompt. Relevance, tool enablement, server behavior, and your approval settings all affect whether a call occurs.

3. Configure an MCP server in Cursor

Project-specific configuration

Put project configuration in .cursor/mcp.json at the repository root. A generic local-server template looks like this:

{
  "mcpServers": {
    "example-server": {
      "command": "your-mcp-server-command",
      "args": ["--workspace", "${workspaceFolder}"],
      "env": {
        "SERVICE_TOKEN": "${env:SERVICE_TOKEN}"
      }
    }
  }
}

Replace the command, arguments, and environment variables with values documented by the server you are installing. Keep secrets in environment variables or the server’s OAuth flow rather than committing them to a repository.

Global configuration

Use ~/.cursor/mcp.json when the same integration should be available across projects. Project configuration is useful when a repository has its own tools or permissions; global configuration is convenient for personal services used everywhere.

Programmatic registration

Cursor also documents an extension API for registering MCP connections programmatically. This is useful when an organization provisions integrations through an extension or managed development environment. The exact API surface can change, so follow the current Cursor documentation when implementing it.

Transport choices

Transport	Use it when	Operational concern
stdio	The server runs as a local command managed by Cursor.	The command, runtime, files, and environment must exist on each developer machine.
SSE	You need a server reachable over a network endpoint.	Protect the endpoint and credentials; account for network failures.
Streamable HTTP	You need a remote HTTP connection supported by the server and Cursor.	Apply normal HTTP authentication, rate limits, and observability.

4. Tools: what Agent can call

The MCP tools model allows a server to expose named operations with descriptions and input schemas. Language models can discover and invoke those tools according to context and user prompts. A tool might search a knowledge base, inspect an issue, run a deployment check, or create a ticket.

Good tool descriptions state what the operation does, required inputs, side effects, and failure conditions. Narrow tools are easier for Agent to select correctly than one operation that accepts arbitrary commands.

Read tools and write tools

• Read tools return information and usually have no external side effect.
• Write tools change state in another system. Treat operations such as sending messages, merging code, deleting records, or deploying as consequential actions that deserve explicit review.

5. Context: bringing external information into a task

MCP can supply context as well as actions. For example, an Agent task can retrieve an internal design document, look up an issue’s acceptance criteria, and then propose a code change using that information. Cursor documentation uses internal documentation and project-management systems as examples, including services such as Notion, Google Drive, and Linear.

Context quality depends on the server. Check whether it returns complete records, stable identifiers, permission-filtered results, and enough metadata for Agent to distinguish similarly named items. If a result is incomplete, ask Agent to show the source or identifiers it used before acting on it.

6. Automation patterns that work well

Research then change

1. Ask a read-only tool for the relevant specification or issue.
2. Have Agent summarize the constraints and identify missing information.
3. Review the plan.
4. Allow a write tool only after the plan is correct.

Contextual code review

Connect a documentation or issue tracker server, then ask Agent to compare the current implementation with the external requirements. Keep the first pass read-only so the result is a review you can inspect before changing files.

Project updates after a change

After a local code change, Agent can use a read tool to find the matching work item and a write tool to add a summary. Require approval for the update and verify the target identifier before allowing the write.

Screenshot evidence for an interface task

An MCP server can expose a screenshot tool so Agent can capture a rendered page, inspect visual output, and iterate. ScreenshotNeo provides an MCP server with take_screenshot, get_page_info, and capture_pdf tools for AI agents such as Cursor.

7. Approval, enablement, and Auto-run controls

Cursor documents controls for enabling or disabling MCP tools. By default, Agent asks for approval before using an MCP tool. An Auto-run setting can change that approval flow and allow tool use without an individual prompt.

Control	What it changes	Recommended practice
Tool enabled/disabled	Whether Agent can consider a particular MCP tool.	Enable only tools needed for the current project.
Approval prompt	Whether you review a call before it runs.	Keep approval for write or externally visible actions.
Auto-run	Whether calls can proceed without an approval prompt.	Use only for trusted, low-impact workflows with bounded permissions.

Approval is a user control, not a guarantee that a server or tool is safe. Review the server’s source, permissions, network access, and credential handling before enabling it.

8. Authentication and permissions

• Use environment variables for tokens when the server supports them.
• Use OAuth when the server documents OAuth and you need delegated access.
• Grant the smallest useful scope: read-only access for research, narrowly scoped write access for updates.
• Do not place long-lived secrets in .cursor/mcp.json if the file is committed.
• For remote servers, protect the endpoint with authentication and monitor failed requests.

9. Troubleshooting MCP in Cursor

Symptom	Likely cause	Fix
Server does not appear	Invalid JSON, wrong file path, or unsupported configuration key.	Validate .cursor/mcp.json, confirm the project root, and compare the keys with the server’s setup instructions.
Local server exits immediately	Missing runtime, command, argument, or environment variable.	Run the command outside Cursor with the same environment and correct the first startup error.
Tool is listed but unavailable	The tool is disabled or the server did not advertise it successfully.	Enable the tool, restart the connection, and inspect the server logs.
Agent never calls a relevant tool	The tool description is vague, inputs are ambiguous, or the tool is not enabled.	State the desired operation explicitly, enable the tool, and improve the server’s name and description.
Approval prompt never appears	Auto-run is enabled or the action is not being selected.	Review Auto-run and per-tool settings; ask Agent to explain whether it selected a tool.
Authentication failure	Missing, expired, or incorrectly scoped credentials.	Refresh the token or OAuth grant, verify environment-variable names, and check required scopes.
Remote calls time out	Endpoint network path, server load, or proxy problem.	Check endpoint reachability, proxy settings, server logs, and request limits.
Wrong record or project changed	Ambiguous names or excessive permissions.	Use stable IDs, ask Agent to confirm the target, and reduce write scope.

10. Performance, reliability, and cost

• Latency: every remote lookup adds network and server time. Retrieve only the records needed for the current step.
• Reliability: design workflows so a failed read does not trigger a write. Make write operations idempotent where possible and return clear errors.
• Context size: return focused results with identifiers and timestamps instead of entire databases or long documents.
• Concurrency: avoid launching multiple writes whose order matters unless the server defines safe ordering.
• Cost: MCP itself does not define a price. Your server may incur hosting, API, model, or SaaS charges; check each provider’s terms.
• Observability: log tool name, duration, status, and a request identifier without logging secrets.

11. Or skip the browser setup

If your Cursor workflow needs rendered screenshots, ScreenshotNeo gives you an API and MCP server without maintaining a browser. It accepts a URL and returns PNG, JPEG, WebP, or PDF. Cookie and consent banners are accepted before capture, and more than 60 known consent platforms, newsletter popups, and chat widgets can be removed; each step can be turned off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the result with X-Page-Verdict and X-Billed headers.

See the ScreenshotNeo API and MCP documentation for setup and options.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const data = Buffer.from(await res.arrayBuffer());
require('node:fs').writeFileSync('shot.webp', data);

ScreenshotNeo also supports full-page capture with lazy images loaded, element selectors, dark mode, device presets and custom viewports, retina scale, PDF paper and page options, custom CSS and JavaScript, clicks, selector or network-idle waits, request blocking, headers, cookies, user agents, Authorization, timezone, geolocation, transparent backgrounds, resizing, cache TTLs, signed links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, usage data, and an OpenAPI specification. Its parameter names match those used by other screenshot APIs, which simplifies migration.

The MCP server exposes take_screenshot, get_page_info, and capture_pdf so Cursor Agent can request captures or page information as part of a task. Every feature is available on every plan. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

12. A practical MCP checklist

• Choose a server that exposes the exact read or write capability you need.
• Decide whether the connection should be local stdio or remote.
• Place project settings in .cursor/mcp.json or global settings in ~/.cursor/mcp.json.
• Keep credentials in environment variables or OAuth.
• Enable only the tools required for the task.
• Keep approval enabled for consequential actions.
• Use stable IDs and narrow permissions for writes.
• Log failures and measure slow external calls.
• Test the read path before enabling automation that changes state.

FAQ

Does MCP replace Cursor Agent?

No. Cursor remains the client and Agent remains the task-oriented assistant; MCP supplies additional tools and external context.

Can an MCP server provide data without changing anything?

Yes. A server can expose read-only tools or context retrieval. Whether it can write depends on the server’s implementation and permissions.

Is every MCP tool run automatically?

No. Agent selects tools when relevant, tools can be disabled, and Cursor normally requests approval before a call. Auto-run changes that approval behavior.

Should I use project or global configuration?

Use project configuration for repository-specific integrations and global configuration for services you intentionally share across projects.

Can Cursor use a remote MCP server?

Cursor documents remote-capable SSE and Streamable HTTP options in addition to local stdio execution. The server must support the transport and authentication method you choose.

What is the simplest way to give Cursor screenshot capabilities?

Connect ScreenshotNeo’s MCP server, or call its screenshot API directly. It handles browser capture and removes common consent banners, popups, and chat widgets before the image is returned.