If you want Cursor to write code that sticks to your data, services, and documentation, MCP Cursor is the most direct approach. It is also a solid base for vibe codding, but with reliable tools and context (Supabase, API, search) to avoid approximate code.
MCP Cursor in 2 minutes: what it is and why it changes your work
MCP stands for Model Context Protocol. The idea is simple: in your Cursor IDE, you connect an MCP server that exposes tools. Then, the AI model can call these tools during development. Instead of “guessing”, he can read a context, query an API, search, or retrieve useful data.
In practice, MCP Cursor allows you to:
- Link Cursor to Supabase to explore tables, understand the schema, and generate code consistent with your data.
- Add an MCP search server (Brave, for example) to find the right documentation and check a version.
- Making the coding flow more reliable: less back and forth, less “off-the-ground” code, more testing and validation.
If you only need to remember one thing: MCP Cursor is the clean bridge between your IDE and your services.
Start quickly: install and first MCP configuration in Cursor
The quickest path is to add an MCP server and then verify that it appears in Cursor. Cursor reads a JSON configuration, often placed in an mcp.json file. The Cursor doc indicates a global configuration via ~/.cursor/mcp.json to make tools available everywhere.
Where to put the configuration file
Start simple: set the configuration to global.
- MacOS/Linux: ~/.cursor/mcp.json
- Windows: the principle is the same, an mcp.json file in the Cursor config folder
Cursor documents this file as the main entry point.
You may also want one configuration per project, especially for collaboration. Some use.cursor/mcp.json. Depending on the version, there may be cases where the local file is not taken into account. If you have any doubts, go back to global to validate that everything is working.
Verify that MCP is active in the IDE
Once your MCP server is added, go to Cursor:
Settings, then Cursor Settings, then Tools & MCP.
This is where you see the servers, their status, and the tools available. After authorization, a reboot may be required for Cursor to detect all features.
MCP Cursor with Supabase: the most useful connection to code with your data
If you use Supabase, MCP gives you an immediate advantage: Cursor no longer needs to invent the structure of your database. It can rely on the diagram, the tables, and reliable information on the documentation side. This is exactly the type of context that improves a development flow.
Setting up the Supabase MCP server in Cursor
Supabase provides an MCP guide and shows how to check the connection in Cursor (Tools & MCP).
In your ~/.cursor/mcp.json, you can start with a very simple setup. The example below gives you a clear basis. Adapt the name if you want.
{
“mcpServers”: {
“supabase”: {
“url”: "https://mcp.supabase.com/mcp”
}
}
}
Then, restart Cursor if necessary, then go back to Tools & MCP to check that the server is connected. Supabase also recommends testing in natural language, for example by asking the model to list tables using MCP tools.
Scoping Supabase access to stay clean and serene
When you connect an IDE to services, the configuration must remain strict. This is true for Supabase, especially if you want to avoid a bad call in a bad environment.
Here's a simple rule: start read-only, on a dev or test project. Then expand if you have a good reason.
Supabase highlights the fact that the connection requires authorization, and that the status is visible in the MCP client (like Cursor).
In your process, think like a dev:
You configure, you test, you validate, then you iterate. You don't “plug everything in” all at once.
How to use Supabase MCP on a daily basis in Cursor
The aim is not to pile up orders. The objective is to improve your coding, step by step, with reliable tools.
A very efficient flow looks like this:
You start by asking the AI model to get the schema, then you ask it to generate the code on the app side, then you force it to write tests.
Examples of simple, work-oriented prompts:
- “List tables and relationships. Use MCP Supabase tools.”
- “Propose TypeScript types for this data, then generate the access code.”
- “Write an integration test and a validation SQL query.”
What is changing here is the context. Cursor can rely on your data. The code is getting fairer, faster.
Add a Brave search MCP server for up-to-date web documentation
Even with Supabase, you'll often have to look for doc info, a version, an API setting, or a configuration option. An MCP search server is for exactly that.
Brave offers an open source MCP server, with a mandatory BRAVE_API_KEY variable. It also supports several transport modes, including stdio and http.
Why it's useful in Cursor
Cursor is great for writing code. But on a fast-moving doc, search remains a key point.
With Brave MCP:
- You can find the right web documentation without leaving your IDE.
- You reduce version errors.
- You can ask the model to cite or summarize the found documentation, then adapt your code.
It's a good habit for anything related to an API, a configuration, or a recent change.
Install Brave MCP and set it up in mcp.json
The Brave repository indicates supported variables, including BRAVE_API_KEY, and specifies a default transport in stdio.
Côté Cursor, you can declare an MCP server “command” via Node. You can also avoid putting a key in plain text by using an environment variable. Cursor documents the use of variables in mcp.json.
Example of a simple configuration, in studio:
{
“mcpServers”: {
“supabase”: {
“url”: "https://mcp.supabase.com/mcp”
},
“brave-search”: {
“command”: “npx”,
“args”: [” -y”, "@brave /brave-search-mcp-server “],
“env”: {
“BRAVE_API_KEY”: “$ {BRAVE_API_KEY}”
}
}
}
}
Then, you define BRAVE_API_KEY in your local environment, then you launch Cursor again. The idea is to have a stable, versionable configuration, and without leaking secrets.
Quickly test the search part
To validate, do three simple tests in Cursor:
First a documentation request, like “Find the official X documentation, then summarize useful options.”
Then a version request: “Check the current version, and give the breaking changes”.
Finally, a code-oriented test: “Look for an example of how to use the API, then adapt the snippet to my code”.
If these three points pass, your Brave MCP server can be used in your feed.
How MCP really works in Cursor: the minimum you need to understand
You don't need to know all the theory to be effective, but you need to know three things: server, tools, transport.
An MCP server exposes tools. Cursor acts as a client. The model can then call these tools in the IDE whenever it needs them during development.
Tools, resources, prompts: why do we find our way around quickly
Depending on the implementations, an MCP server can expose:
Tools, which are actions, such as “do a search”, “list tables”, “execute a query”.
Resources, which are searchable resources.
Sometimes prompts or helpers, depending on the SDK and server.
In real life, you use it for two things: retrieving reliable context, then producing code that sticks to that context.
The choice of transport: stdio or HTTP
Transport is how Cursor talks to the MCP server.
Locally, stdio is very common and simple. It goes through the standard input and output of the process. This is useful for a Node tool launched on command.
For remote services, you can use HTTP variants. Some docs indicate that SSE existed and can still be supported, but recent sources mention that the standard is evolving and especially recommends stdio, with streaming-type HTTP for some cases.
My advice: start in studio for your local tools and your search. And uses an HTTPS URL when the provider offers a managed server, like Supabase.
A development flow that works: Supabase, code, tests, then docs
Vibe codding works when the flow is short, but it becomes powerful when MCP brings the right tools, data, and docs at the right time.
The best use of MCP Cursor is a clear process. Not a demo. Not a gimmick.
Here is a simple work guide that you can repeat for each feature.
Step 1: frame the data before writing code
You ask the model to retrieve the schema and the constraints. You validate what you read.
You can then ask him to rephrase the data in the form of types, or domain objects. You get a cleaner, more stable code.
Step 2: generate data access and functions on the API side
With Supabase, you can produce:
Read requests.
Filters.
Pagination.
Service functions, with a clear signature.
At this point, you're insisting on clarity. You want simple code. You want stable names. You want testable functions.
Step 3: Write a test that proves that the feature works
This is where MCP Cursor becomes very profitable.
You ask the model:
To write a unit test on logic.
Then an integration test that verifies the request or the API.
Then a short checklist of edge cases.
This trio improves your flow. And it reduces the time lost “guessing” where a bug comes from.
Step 4: Update internal documentation and docs
When the code is good, you want useful docs:
A short, usage-oriented README.
A “configuration” section that describes the variables.
A reminder of test orders.
You use Brave search if you need to cite a web doc or check a parameter.
Security and configuration: stay in control when you connect services
MCP makes tools powerful. So your configuration should be kept clean.
The most important point is to limit access.
You avoid plugging in the product until you have a clear process. You prefer a test project. You're using minimal rights. You limit what is possible, especially at the beginning.
Supabase points out that authorizing and detecting tools may require a reboot and verification in the client. It reminds us of a key point: these connections are real, and they should be treated as an integration.
On the Brave side, keep your key out of the file. Go through an environment variable. The Brave server explicitly supports BRAVE_API_KEY.
Diagnosing an MCP that is not responding in Cursor, without wasting an hour
When it crashes, it's almost never “mystical.” It's often the configuration, the command, or the authorization.
Start with these simple questions.
Is the mcp.json file in the right place, and well-formed in JSON.
Is the server really starting up. For a command server, are Node and npx available.
Are environment variables present, especially for Brave.
In Cursor, does the server appear in Tools & MCP, and is it connected.
If you've set a config to the project level and Cursor doesn't read it, try the global config ~/.cursor/mcp.json to isolate the problem. Community feedback goes in this direction on some versions.
Collaboration: making MCP Cursor useful in teams
MCP Cursor is not only a personal tool. Well set up, it helps a team produce more consistent code.
The idea is to have a simple process:
A shared configuration, when possible.
Internal doc instructions, so everyone sets up the same way
A test protocol, to validate that an MCP server is responding.
Concretely, you can document:
How to install Cursor.
Where to put the configuration.
How to set up Supabase, what services are allowed.
How to set up Brave, and where to put the key.
What test commands to launch after an update.
You're reducing friction. You make the work better. And you make development more fluid.
MCP Cursor: what you can do next to go faster and write better
Once Supabase and Brave are in place, you can extend MCP to other services:
An MCP server for your design system, in order to retrieve internal documentation.
An MCP server for your backlog, in order to link the coding to the tickets.
An MCP server for a monitoring tool, in order to correlate errors and version changes.
You don't have to do everything. The right criterion is simple: does it improve your flow, and does it reduce errors.
MCP Cursor is a discipline guide as well as a tool guide.
Go further with Scroll
If you want to set up MCP Cursor cleanly, with a solid configuration, a test flow, and a Supabase integration adapted to your product, the Scroll agency can help you. We often work on digital transformation and AI topics in the IDE: choice of MCP servers, configuration, security, documentation, and the establishment of a development process that lasts over time.
Faq
MCP Cursor refers to the use of Model Context Protocol in Cursor to connect the IDE to an MCP server. This server exposes tools that the AI model can call during development, for example to read documentation, do web search, or query data via an API. Result: the generated code better fits the real context of the project.
You add an MCP server via the configuration (often a file) mcp.json), then you check in Cursor, on the Tools & MCP side, that the server is well connected and that its tools are visible. Then, run a simple test: ask the model to use a tool (example: list Supabase tables or do a Brave search) and check that the action is executed.
Start by setting up Supabase on a dev or test project, ideally read-only. Extend to the maximum what the server can see and do. Once connected, use MCP to retrieve the schema and useful data, then have the data access code and tests generated. The key point is to keep a clear and controlled configuration, especially if several services are connected.

.png)





