Get started

Quickstart with MCP

Connect your agent to Nevia over MCP, create a Postgres database, and branch it to test changes

This quickstart runs the same exercise as the Quickstart, but your coding agent does the work. It connects over MCP, creates a Postgres database and branches it. The branch is a copy of your data you can change while the original keeps running.

Prerequisites

You need:

  • A coding agent that supports MCP and can run local terminal commands, such as Claude Code, Codex or Cursor.
  • A browser for sign-in.
  • The psql Postgres client, installed where your agent runs terminal commands.
  • A Nevia workspace where you have the admin or editor role. Nevia creates a default workspace the first time you sign in, so a new account already qualifies.

The agent manages databases with Nevia's MCP tools and runs SQL with psql. You don't need the Nevia CLI.

If psql is missing, install it:

# macOS
brew install libpq && brew link --force libpq

# Debian / Ubuntu
sudo apt install postgresql-client

Check the install:

psql --version

This prints the Postgres client version.

Add the server

Claude Code and Codex take one command. Cursor takes one click. Any other client that supports Streamable HTTP needs only the server URL:

claude mcp add --transport http nevia https://api.nevia.cloud/mcp

Then sign in. In Claude Code, run /mcp and pick nevia to open your browser. In Codex, run codex mcp login nevia. Cursor and most other clients show a sign-in button next to the server. The tools appear after you sign in. If they don't, restart or reconnect the client.

Use the URL without ?readonly=true. This exercise needs write tools.

Select a workspace

Ask your agent:

Using the Nevia MCP tools, show my workspaces and my role in each.

The agent lists your identity and workspace IDs. Pick a workspace where you are admin or editor; default works. Then give the agent its full ID:

Use workspace 01d4cnjjq40hnnh0nwmkg35nv2h for this exercise. Check that the database names orders
and orders-staging are available. If either name is taken, stop and tell me.

Replace 01d4cnjjq40hnnh0nwmkg35nv2h with your workspace ID. If the agent reports a taken name, ask it to delete that database or choose another name. The database tools reference lists the tools the agent uses.

Create a database

Version, size and storage take platform defaults, so the agent needs only a name:

In the selected workspace, create a Postgres database named orders with the
defaults. Show its name, ID and state. Leave credentials out of your summary.

The result shows orders, an ID and state ready, with no pending transition. If an operation is still in progress, the agent should follow the tool's next_steps and track the existing operation instead of repeating the create call. See Waiting in the Remote MCP server reference.

Set up a schema and some data

Ask your agent to connect and run SQL:

Get the connection for orders. Use psql in your terminal to run this SQL,
keeping the connection’s sslmode=require or stricter setting. Show the query
result without printing the credentials. Stop if a command fails.

CREATE TABLE IF NOT EXISTS pings (id serial PRIMARY KEY, note text);
INSERT INTO pings (note) VALUES
  ('csv-note-one'), ('csv-note-two'), ('baseline-a'), ('baseline-b');
SELECT count(*) FROM pings;

The count is 4, which also confirms the agent can reach the database. If connection details are missing or the endpoint is unreachable, see Databases in the Remote MCP server reference.

Branch the database

A branch copies the parent's data into a new database with its own connection string. The source must be ready, with no pending transition or running operation, and have a persistent data disk supplied by the deployment.

Branch orders as orders-staging. Check that the branch is ready, then get its
connection and use psql to count the rows in pings. Show the count before
making any changes.

The branch has 4 rows, and the source keeps running. Now have the agent change the branch:

Run this SQL against orders-staging only. Show the command results.

INSERT INTO pings (note) VALUES ('branch-mutation');
UPDATE pings SET note = 'baseline-a (edited in branch)' WHERE note = 'baseline-a';

The agent reports INSERT 0 1 and UPDATE 1.

Check the divergence

Ask your agent to compare the two databases:

Run this query against both orders and orders-staging. Label each result with
its database name so I can compare them.

SELECT count(*), array_agg(note ORDER BY id) FROM pings;

The source still has 4 rows, and baseline-a is unchanged. The branch has 5 rows, including branch-mutation and baseline-a (edited in branch). Your changes stayed in the branch.

Clean up

Open the console, select the same workspace, and find orders and orders-staging under Databases.

Delete both databases and their data. Deleting the source leaves its branches running, so name both:

Show me orders-staging and orders in the selected workspace and ask me to
confirm deletion. Then delete those two databases. List databases by each
name afterward to verify cleanup.

After you confirm, each name lookup returns an empty list and neither database appears in the console.

Next steps

On this page