Use these Cursor MCP config examples as practical starting points for developer workflows: local repository access, GitHub context, documentation or search tools, and multiple MCP servers in one config file.
These snippets are independent examples for developers and are not official Cursor documentation. Always verify the current Cursor MCP settings screen and each MCP server maintainer's instructions before using a config locally.
For a safer first draft, use the Cursor MCP Config Generator to create placeholder-based JSON in your browser, then review it before copying anything into your local Cursor setup.
Key takeaways
- Cursor MCP configs usually define servers under a top-level mcpServers object in a local mcp.json file.
- Start with one narrow, read-oriented server before combining filesystem, GitHub, docs, and search tools.
- Keep static examples safe by using placeholders such as ${GITHUB_TOKEN}, ${BRAVE_API_KEY}, and ${NOTION_API_KEY} instead of real secrets.
Before you copy a Cursor MCP config example
Cursor can use MCP servers to give coding agents access to local files, repository context, GitHub issues, docs, search, and other developer tools. A config entry usually includes a local server name, the command to run, command-line arguments, and optional environment variables.
Treat every snippet below as a starting template, not a finished setup. Replace generic paths with your own allowed folders, validate the JSON, check Cursor Settings → MCP for the active config location, and test one server before adding more.
- Use one top-level mcpServers object
- Give each server a short, unique local name
- Keep args as an array
- Use placeholders in public examples
- Avoid committing local mcp.json files with secrets
- Test MCP tools in Cursor Agent mode
Cursor MCP config file location
Cursor setup details can vary by version and workspace. Many setups use an mcp.json file through Cursor Settings → MCP, and some teams keep separate user-level and project-level configs.
Do not assume a public example knows your exact local path. Open Cursor Settings → MCP, confirm where your active config is loaded from, then copy only the server entries you need.
- Check Cursor Settings → MCP first
- Confirm whether you are editing a user or project config
- Restart or reload Cursor after changing config
- Keep private workspace paths out of screenshots and commits
Filesystem MCP config example for Cursor
Use a filesystem server when you want Cursor to inspect a local project, documentation folder, or sandbox directory through MCP tools.
Limit access to specific folders instead of your entire home directory. For a first test, point the server at a harmless project or sample repo before using it with production code.
- Best for local repositories and docs folders
- Use explicit project paths
- Avoid broad home-directory access
- Start read-only where the server supports it
{
"mcpServers": {
"repo-files": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/your-name/Projects/example-app",
"/Users/your-name/Projects/example-app/docs"
]
}
}
}GitHub MCP config example for Cursor
Use a GitHub MCP server when Cursor needs repository, issue, pull request, or organization context from GitHub.
Create a token with only the scopes your workflow needs. Some Cursor versions and server launch methods handle environment variables differently, so verify server-level env support in your local Cursor version and the server documentation before relying on it.
- Use a narrow GitHub token scope
- Prefer read-only access for first tests
- Use ${GITHUB_TOKEN} in examples
- Review write-capable tools before enabling them
- Confirm env handling in your Cursor version
{
"mcpServers": {
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}Docs and search MCP config example for Cursor
Use docs and search servers when Cursor needs external reference material for development tasks, API exploration, or documentation lookup.
Search results and docs pages can contain untrusted instructions. Keep these tools separate from destructive actions, use placeholder API keys in static examples, and avoid sending private repository details to services you have not reviewed.
- Use placeholders for API keys
- Treat web and docs content as untrusted
- Keep docs/search tools read-oriented
- Confirm each package and env name against maintainer docs
{
"mcpServers": {
"brave-search": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-brave-search"
],
"env": {
"BRAVE_API_KEY": "${BRAVE_API_KEY}"
}
},
"notion-docs": {
"command": "npx",
"args": [
"-y",
"@notionhq/notion-mcp-server"
],
"env": {
"NOTION_API_KEY": "${NOTION_API_KEY}"
}
}
}
}Multiple MCP servers in one Cursor config
You can combine several MCP servers in one Cursor config when a coding workflow needs local files, GitHub context, and external lookup tools.
Add servers one at a time. If something fails, temporarily remove the other entries and test the failing server by itself so command, path, dependency, and token problems are easier to isolate.
- Keep server names unique
- Separate repo, GitHub, docs, and search capabilities
- Use placeholders instead of real secrets
- Remove unused servers instead of leaving stale tools enabled
{
"mcpServers": {
"repo-files": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/your-name/Projects/example-app"
]
},
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
},
"brave-search": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-brave-search"
],
"env": {
"BRAVE_API_KEY": "${BRAVE_API_KEY}"
}
},
"notion-docs": {
"command": "npx",
"args": [
"-y",
"@notionhq/notion-mcp-server"
],
"env": {
"NOTION_API_KEY": "${NOTION_API_KEY}"
}
}
}
}Static-site safety notes for Cursor MCP examples
A static, browser-only guide or config generator should never collect, store, validate, or transmit real API keys. Generate copyable placeholder JSON and let developers edit sensitive values locally.
Do not ask users to paste private tokens, private repository names, production paths, or local config contents into a hosted page. Keep examples generic and pair config work with a security checklist before enabling write-capable tools.
- Browser-only generation
- No login required
- No database storage
- No AI API calls
- No real secrets in examples
- Copy locally and review manually
Common Cursor MCP config mistakes
Most Cursor MCP issues come from invalid JSON, a wrong config location, missing Node.js or npx, a server package name mismatch, unavailable local paths, or environment variables that are not available to the launched process.
If a server does not appear, validate the JSON, confirm the command works in a terminal, check Cursor Settings → MCP for the active config path, and test with one server entry at a time.
- Trailing commas or smart quotes
- args written as a string instead of an array
- Wrong mcp.json location
- Missing Node.js or npx
- Bad local folder path
- Token placeholder not replaced in the private local environment
- Testing in Chat mode instead of Agent mode
Implementation checklist
- Choose the Cursor workflow before choosing servers
- Start with one MCP server entry
- Use narrow local filesystem paths
- Use ${GITHUB_TOKEN}, ${BRAVE_API_KEY}, and ${NOTION_API_KEY} only as placeholders in public examples
- Confirm package names and env variable names against each server maintainer's docs
- Validate the JSON before saving
- Check Cursor Settings → MCP for the active config path
- Restart or reload Cursor after changing MCP configuration
- Test in Cursor Agent mode
- Never publish real tokens, private paths, or private repository names
FAQ
Where does Cursor MCP config go?
Cursor commonly uses a local mcp.json file, and some setups support user-level and project-level configuration. Check Cursor Settings → MCP for the active config path before editing.
Can I use the same MCP servers in Cursor and Claude Desktop?
Often yes. The MCP servers may be the same, but the client-specific config location and setup flow can differ. Copy server entries carefully and verify the expected JSON structure for Cursor.
Should I put real API keys in these examples?
No. Public examples, static pages, generated previews, screenshots, and commits should use placeholders such as ${GITHUB_TOKEN}, ${BRAVE_API_KEY}, and ${NOTION_API_KEY}. Use real secrets only in your private local setup.
Why is my Cursor MCP server not working?
Common causes include invalid JSON, a missing dependency such as Node.js or npx, a bad local path, a server package mismatch, missing environment variables, or testing outside Cursor Agent mode.
Can a static website safely generate Cursor MCP config JSON?
Yes, if generation happens entirely in the browser and the site outputs placeholder-based JSON only. It should not collect tokens, call an AI API, store configs in a database, or modify local files.
Is this official Cursor documentation?
No. This is an independent developer guide with example snippets. Always verify Cursor's current MCP UI and the individual MCP server documentation before using a config.