Using Cursor to Build a Web App With an MCP Connector

Cursor plus MCP is a specific technical setup: connect Anthropic's Model Context Protocol to Cursor's editor, and the AI stops working blind. It can read your database schema, pull a Figma file, or check a GitHub issue, all without you pasting context into the chat window every session. That pairing is what turns Cursor from a smart autocomplete into something closer to a junior engineer who actually remembers your project.

Before MCP existed, every coding session in Cursor started the same way: re-explain the folder structure, re-paste the database tables, re-describe what the API returns. The model was capable, sure, but it had no eyes. No access to your disk, your live database, or any outside service unless you typed it out by hand, every single time. Anthropic introduced MCP in November 2024 as a fix for exactly this, an open standard built by engineers David Soria Parra and Justin Spahr-Summers that gives AI models a standard way to plug into external tools and data.

Anthropic's own comparison is a USB-C cable: one connector that works everywhere, instead of a drawer full of incompatible adapters for every device you own. That's the shift MCP represents. Traditional plugins extend what an app can do. MCP extends what the model itself can do, and the model decides on its own when to reach for a tool, without you spelling out the command each time.

Before the standard caught on, every AI tool, Cursor, Claude Desktop, whatever else, was building its own one-off database connector. Same problem, solved a dozen different incompatible ways, with a dozen different maintenance headaches. MCP flipped that: build a connector once to the MCP spec, and it works across every MCP-compatible app. Adoption moved fast after November 2024. OpenAI, Google, and Microsoft all support the standard now, thousands of MCP servers exist built by outside developers, and SDKs are available in every major programming language.

What Cursor is and who is actually using it

Cursor's founding team met at MIT and started out building AI tools for CAD software, not code editors at all. In 2022, they began building AI coding tools and launched a public AI-native code editor in 2023, betting that software engineering itself could be largely automated by an editor built around AI from the ground up rather than bolted on after.

The growth numbers back the bet. Cursor crossed $1 billion in annualized revenue in November 2025, then hit $4 billion ARR by May 2026, just 31 months after it first crossed $1 million ARR back in October 2023. Bloomberg reported in March 2026 that the platform had passed 1 million daily users and 50,000 businesses running on it.

The 2025 Stack Overflow developer survey, covering more than 49,000 developers across 177 countries, gave Cursor an 18% usage share among AI-enabled editors in its first year appearing in the rankings. GitHub Copilot led at 68%, but Cursor beat Claude Code's 10% right out of the gate. A University of Chicago study cited on Cursor's blog in November 2025 found that companies merge 39% more pull requests once Cursor's coding agent becomes the default tool for a team, a real productivity signal, not just adoption noise.

Cursor 2.0 shipped in October 2025 with support for running multiple agents in parallel, using git worktrees or remote machines to let several coding tasks run at once. That's the direction the tool is headed: less single-shot autocomplete, more multi-step agentic work. Which is exactly why MCP matters here. A tool operating at this scale, with numbers like these behind it, is worth setting up properly. MCP is what closes the gap between an AI that writes code and an AI that actually understands the project it's writing code for.

How MCP works inside Cursor before touching a single config file

Three pieces make up the architecture. Cursor itself is the MCP Host. Inside it sits an MCP Client, which manages the connection. On the other end is an MCP Server, a small program that wraps whatever external service you're connecting to: a database, an API, a filesystem.

They talk to each other using JSON-RPC, a structured message format that stays the same no matter what's on the other side of the connection. That consistency is the whole point.

Here's what changes once it's wired up. Ask Cursor to "show me orders for user ID 123 from the last month," and it connects to the database on its own, checks the actual table structure, writes the SQL, runs it, and formats the results back to you. Nobody told it to "query the database." It figured that out because the tool was available and the request implied it.

Compare that to the old way: paste the table structure into chat, explain how the tables relate to each other, specify exactly which fields matter, every single time you needed something from the database. MCP servers in Cursor come in two scopes. Global servers live in ~/.cursor/mcp.json and are available across every project. Local servers live in .cursor/mcp.json inside a specific project folder, scoped to just that codebase.

One useful bit of trivia: MCP clients such as Cursor and Claude Desktop share the same underlying JSON config format. Learn it once in Cursor, and that knowledge carries over if a project ever needs a different client. The confirmation that a server is actually working shows up as a green status indicator in the MCP settings tab. If that indicator's missing, the most common culprit is a stale connection, and restarting the client usually clears it.

Step-by-step: opening Cursor's MCP settings and adding a first server

The path is short: File, then Preferences, then Cursor Settings, then the MCP tab. From there, two buttons matter. "Add new global MCP server" sets something up for use across every project. "Create New MCP Server" scopes it to whatever project is currently open.

Under the hood, it's just JSON. A time server, for example, looks like this in mcp.json:

{ "mcpServers": { "mcp_server_time": { "command": "python", "args": ["-m", "mcp_server_time", "--local-timezone=America/New_York"] } } }

Before that config does anything, the package itself needs installing: pip install mcp-server-time. Finding servers to add isn't a guessing game either. The MCP Registry, linked from the official modelcontextprotocol/servers repository, lists community-built options, and Smithery (smithery.ai) is a second catalog worth checking.

Once a server's configured, using it is simple: press Ctrl+L to open the chat panel, and click "Run tool" when Cursor offers it. The mcp.json file is read by Cursor when it starts up, making configured servers available in the session. Again, check for the green indicator in the MCP tab to confirm it's live, and restart the client if it's not showing.

One limitation worth flagging early, since it trips people up: ChatGPT can't run local stdio-based servers, the kind using command: "node" or command: "npx". Those need a bridge like mcp-remote or a hosted version of the server instead. Cursor doesn't have that restriction, which is one practical reason it's become a default for this kind of setup.

Adding a database connector: Supabase MCP as the practical web-app backbone

Supabase ships an official MCP server that connects Cursor, and other clients too, straight to a Supabase project. Once it's set up, database work happens in plain English inside the chat window, no context switching to a separate SQL editor.

Setup is quick. There's a hosted endpoint at mcp.supabase.com, or it can run locally through npx @supabase/mcp-server. Setup is straightforward either way.

One thing to be careful about: the server connects using the service role key, which carries elevated privileges, so the key needs to be guarded carefully. For any production database, starting with read-only access is the safer default until there is a real reason to allow writes.

Once it's connected, the range of what Cursor can do expands quickly. Ask it to "design a normalized schema for a multi-tenant SaaS with organizations, team members, and role-based permissions," and it'll draft one. Ask it to "add a subscriptions table that references users and integrates with Stripe webhook events," and it inspects the existing schema first, understands how the tables already relate, and writes migration code that actually fits, not a generic guess pulled from a tutorial.

Beyond schema design, the same connection handles natural-language SQL queries, automated migrations, TypeScript type generation straight from the live schema, and general database debugging. Worth noting: the MCP spec revision from March 2025 adds official OAuth support, so future versions of this setup should authenticate with Supabase through standard OAuth instead of a manually generated personal access token sitting in a config file.

A reasonable starter stack alongside Supabase, drawn from commonly referenced MCP server options: GitHub integration through @modelcontextprotocol/server-github, Postgres through @modelcontextprotocol/server-postgres, and SQLite through @modelcontextprotocol/server-sqlite for anything running locally.

Connecting a Figma design to Cursor via MCP to generate working front-end code

The Figma MCP Server sends a Figma file directly into Cursor and comes back out as working HTML, CSS, and JavaScript. Not an exported image, not a plugin's approximation of code. Actual code, running in a local dev environment, ready to edit.

The workflow follows a pattern:

• Connect the Figma MCP Server to Cursor through the same MCP settings path used for any other server.
• Clean up the Figma file first: clear component names and proper auto layout make a real difference in how well the translation comes out.
• Prompt Cursor to generate from the design. It reads the file through the MCP connection and produces a working front end.
• Correct it in plain language. Something like "fix the button style and make the inner part 80 by 80 px" gets the code updated and the UI regenerated to match.

That last part is where this stops feeling like a prototype tool and starts feeling like a real front-end workflow. The output is editable code sitting in a real codebase, not a locked design file. Paired with the Supabase connection from the last section, a builder can go from Figma file, to working front end, to a database-connected back end, without ever leaving Cursor's chat window.

Configuring Cursor with rules and context to get consistent results across sessions

Consistency doesn't happen by accident. The combination that actually works is MCP servers, rules files stored at .cursor/rules/*.mdc, memories, and auto run mode, set up together at the start of a project rather than added later once things are already messy.

Vague prompts get vague results. Ask for "a button component" and the output varies wildly session to session. Ask instead for "the Primary CTA Button in the Header using Shadcn components," and the result matches what the rest of the project actually looks like.

Rules files are where project conventions live: which component library to use, naming patterns, how folders are organized. Without them, Cursor has to rediscover those conventions from scratch every session, which is exactly the re-explaining problem MCP was supposed to solve in the first place. Practitioners using this combination have reported that it can take a refactor that might otherwise eat days down to a few hours, and lets API integrations that normally need heavy documentation review get implemented correctly on the first attempt.

Cursor, at its core, is making guesses based on whatever context it has. Rules are what steer those guesses toward a project's actual patterns instead of whatever the model considers a sensible default. Auto run mode, once the MCP connections and rules are verified as correct, lets the agent execute its own tool calls without stopping to ask permission at every single step, which is where a lot of the time savings actually come from.

Expanding the MCP stack as the app grows

Once the base setup, database plus design plus rules, is working, adding more servers is just repeating the same JSON pattern already learned. A few practical additions:

• GitHub MCP (@modelcontextprotocol/server-github): check unresolved issues, open pull requests, manage branches, all from inside Cursor's chat.
• Slack MCP: post a deployment notification to a channel, or check for mentions, without switching apps.
• Fetch Server: pull articles or documentation off the web into a format the AI can actually reference, instead of copy-pasting text by hand.
• Chrome DevTools MCP: open a page, read the DOM, run JavaScript, check performance, basically browser testing from inside the coding session.
• A design system MCP server: pull internal component docs so Cursor references the actual design system in use, not a generic pattern it's seen elsewhere.
• A backlog or ticketing MCP server: tie coding work directly to project tickets so nothing gets lost between the two.

The ecosystem keeps widening past pure dev tooling too. Vendors including Notion, Asana, Intercom, and Sentry have shipped official remote MCP servers, which means the same connector pattern now reaches into general business operations, not just code.

Scale changes the calculus, though. Local servers installed through npx or pip, with keys sitting in plaintext config files, are fine for one person experimenting. Once several developers are sharing the same integrations, a managed gateway like Composio makes more sense: a shared team MCP endpoint, controls over which tools each person can call, and an audit trail for every request that goes through it.

What Cursor's pricing actually means for a builder using MCP heavily

Cursor runs six plans: Hobby (free), Pro at $20 a month, Pro+ at $60, Ultra at $200, Teams at $40 per user per month, and Enterprise, which is custom-priced.

Hobby needs no credit card, but Agent requests and Tab completions are capped tightly, with a one-week Pro trial thrown in for new accounts. It's fine for kicking the tires. It is not enough for daily professional work.

The bigger shift happened mid-2025, when Cursor moved off a request-based billing model onto a credit-based one. What that means practically: how far a dollar goes now depends on which underlying AI model gets used and how complex the prompts are. MCP-heavy sessions, the kind running real database queries through Supabase or multi-step agent tasks across several tools, burn through more credits per session than a simple autocomplete ever would.

Pro at $20 a month is the realistic floor for anyone running an MCP-connected workflow on a daily basis, but heavy agentic use under the credit system can push spend up toward Pro+ territory without much effort. Anyone serious about this setup should read the credit system's fine print closely: know exactly what's covered under the plan versus what model usage you're paying for on top of it, since that's where the real cost of a heavily automated workflow ends up hiding.

What a complete Cursor + MCP web app looks like

Put the pieces together and the shape of the finished setup is fairly concrete. A Figma file feeds into Cursor through the Figma MCP Server and comes out as real front-end code. That front end talks to a Supabase database wired in through Supabase's MCP server, with schema, migrations, and types all generated from inside the same chat window. Rules files at .cursor/rules/*.mdc keep the AI's output consistent with project conventions across sessions, and auto run lets the agent carry out multi-step tasks without a confirmation prompt at every turn.

Around that core, additional MCP servers, GitHub for issues and pull requests, Slack for deployment pings, Chrome DevTools for testing, plug in using the exact same JSON pattern learned on day one. None of it required learning a new protocol twice. That's the actual argument for MCP inside Cursor: one connection standard, reused across every tool a web app actually needs, instead of a patchwork of one-off integrations that all have to be relearned from scratch.