Connect Cursor or Claude Code to a real backend via MCP

Coding agents write frontend code well. The gap has always been everything underneath it — a database, authentication, file storage, API endpoints, and a place to deploy — because those were built for humans clicking through dashboards, not for an agent operating from a terminal. MCP is the protocol that closes that gap, and it's worth understanding even if you've only used it for one or two tools so far.

What MCP actually is

Model Context Protocol (MCP) is an open standard, introduced by Anthropic, that lets an AI assistant connect to external tools and services through one consistent interface. Instead of every backend having its own bespoke API your agent has to be taught, an MCP server exposes a standard set of callable tools — and any MCP-compatible client (Cursor, Claude Code, Codex, Windsurf, and others) can discover and use them the same way.

Concretely: you install an MCP server, your agent's client connects to it, and the agent can now see and call whatever tools that server exposes — no separate integration code, no custom prompt engineering to teach it your API shape.

Why this matters for a backend specifically

Generating a React component is a self-contained problem — the agent writes the file, you see the result. A database is not self-contained: creating a table, running a migration safely, writing an authenticated endpoint, or deploying a change all involve state that lives outside your repo. Before MCP, the practical options were either giving the agent raw infrastructure credentials (risky, and it still doesn't know your platform's specific operations) or doing that part yourself by hand, breaking the flow every time you needed backend work done.

An MCP server built specifically for a backend platform exposes the operations — create a project, write a database schema, add an auth rule, deploy a workflow — as tools the agent already understands how to call correctly, because they're scoped and named for exactly what they do.

Connecting DYPAI to your IDE

DYPAI's MCP server lives at mcp.dypai.dev and exposes tools for the whole backend lifecycle: creating projects, managing the database and storage, writing and publishing workflows, and deploying the frontend. Setup is one command, run from your project's terminal:

npx -y @dypai-ai/install

This authenticates, registers the MCP server in your IDE's config, and drops agent instructions into your project so your coding agent knows how to use it from the next prompt onward. For a non-interactive setup — CI, a fresh container, or picking the client explicitly — pass it directly:

npx -y @dypai-ai/install --client cursor

The same install works whether your agent is Cursor, Claude Code, Codex, or Windsurf — MCP is the same protocol on every client, so the server doesn't need a different integration per tool.

What changes once it's connected

Once the MCP server is registered, you keep working the way you already do — describing what you want, in your own editor, on your own repo — except now "add a bookings table with a foreign key to users" or "add Google login" are things your agent can actually execute, not just scaffold placeholder code for. Concretely, with DYPAI's server your agent can:

• Create a project and provision its Postgres database
• Write and publish backend flows (dypai/flows/*.flow.ts) that compile to HTTP endpoints, webhooks, and cron jobs
• Add authentication (email, Google, magic links) without you writing custom login/signup endpoints — that's built into @dypai-ai/client-sdk
• Manage file storage buckets
• Deploy the frontend to a hosted URL

Backend changes go through a draft → publish step, so an agent-written migration doesn't hit production silently; frontend deploys go out directly.

A minimal example

Once connected, a prompt like:

"Create a new DYPAI project called bookings, add a Postgres table for appointments with a foreign key to users, and expose a POST endpoint to create one."

is executed through MCP tool calls your agent already has access to — no separate dashboard tab, no copy-pasting a schema into a web UI. If you're evaluating whether an agent-native backend fits your workflow at all versus a prompt-to-app web builder, that's really the question: do you want to keep working from your own IDE, or from a separate app? We cover that split in more depth in what an AI app builder actually is in 2026.