AI assistants (MCP)

PotaLab Base is launching soon. Its MCP server (@potalab/base-mcp) will be available at launch. It connects AI assistants such as Claude Code, Claude Desktop and Cursor to a project through the Model Context Protocol. The assistant can read the schema and API docs, run read-only SQL, check advisors, generate TypeScript types and write @potalab/base code that matches your tables. It can also create, deploy and test Functions and Flows.

From idea to backend

Describe the product you want and let your agent do the work. A typical session looks like this.

Prompt

A booking app: customers, services and appointments. Each owner only sees their own data. Send a reminder when a booking is created. Dry run everything first, then apply it, and generate the types.

What the agent does

1. Look around. list_tables, get_api_docs and project_limits show what exists and what your plan allows.
2. Design the schema. create_table for customers, services and appointments (with dry_run: true it returns the SQL for you to read), then alter_table for changes.
3. Secure it. create_policy and set_rls so owners see only their own rows. get_advisors flags tables without RLS and other issues.
4. Add logic. db_functions_create writes a SQL function such as book_slot (safe defaults: SECURITY INVOKER, empty search_path, EXECUTE granted only where you say), and rpc_call tests it as a given user. functions_create, functions_test_run and functions_deploy handle an Edge Function such as send-reminder, and function_secrets_set stores its secret (write-only, never returned). For a Flow, flows_node_catalog and flows_validate_graph come first, then flows_deploy and flows_test_run.
5. Ship. apply_migration applies the SQL, generate_typescript_types and get_sdk_snippet give you typed client code that matches your tables.

Turn writes on

Everything above that changes your project needs writes. They are off until you enable them for a project.

• OAuth: on the consent page choose the project, grant the scopes the work needs (for example database:write, functions:write, flows:write, credentials:write) and leave the Read-only switch off.
• Access token: give the token the same scopes and start the server with --allow-writes together with --project-ref my-app (or --write-projects a,b).

Review the dry-run SQL before you apply it, and check the project audit log afterwards.

Connect with OAuth

No token to paste. The assistant opens your browser, you sign in (with your second factor if MFA is on) and approve exactly what it may do.

claude mcp add --transport http potalab-base https://base.potalab.com/mcp

Then run /mcp in Claude Code, pick potalab-base and choose Authenticate. The consent page shows the requested permissions in plain language, a project picker (all projects, or only selected ones) and a Read-only switch. Allow sends you back to the assistant; Deny tells it you refused.

Other clients that speak MCP Streamable HTTP with OAuth (Cursor, VS Code, MCP Inspector) use the same URL. Claude Desktop: Settings, Connectors, Add custom connector, with a public HTTPS URL.

Everything the assistant does is done as you, with your organization roles and never more, limited to the scopes, projects and read-only choice you approved. Calls are recorded in the project audit log. Manage access in Account, Connected apps: Revoke access stops every token of that app at once.

Connect with an access token

Create a personal access token (dashboard, Account, Access tokens). Restrict it to the project and give it only the scopes you need: projects:read and database:read, plus database:write for SQL, types and dry runs.

claude mcp add potalab-base \
  -e POTALAB_BASE_API_URL=https://api.example.com \
  -e POTALAB_BASE_ACCESS_TOKEN=lb_pat_… \
  -- npx -y @potalab/base-mcp --project-ref my-app

Claude Desktop and Cursor use the same command, args and env in their mcpServers JSON.

What it may do

Mode	Behavior
Default (read-only)	Reads only. execute_sql runs in a read-only transaction. Table and policy tools return SQL with dry_run: true.
--allow-writes	Adds apply_migration, row writes, set_rls, delete_objects and real create_table, alter_table and create_policy. Only for --project-ref or --write-projects.

Every write is a Management API call, so the same plan limits, roles and audit log apply as in the dashboard and CLI. A refusal because of your plan is an HTTP 402 with plan_limit_exceeded or feature_not_in_plan.

Functions and Flows

An assistant can create and deploy Functions, design Flows, test them as a simulated user and read the result. Scopes: functions:read|write, flows:read|write and credentials:read|write. Write tools exist only with --allow-writes. Secrets and credential keys are write-only: tools accept them and never return them.

Example prompts

• “List my tables and tell me which ones have no RLS policy.”
• “Add a todos table only its owner can see. Dry run first, then create it and generate the types.”
• “Create a Function send-welcome, deploy it and test it as an authenticated user. Show me the logs.”
• “Run project_limits and tell me what I can still create.”

Safety

• Read-only by default. Turn writes on only when you need them, and review proposed changes with dry runs.
• Least privilege. Use project-restricted access and only the scopes you need.
• Prompt injection. Rows, comments and query texts come from your database and may contain text written by anyone who can insert data. The server marks them as untrusted and tells the model not to follow instructions inside them. Still review what an assistant proposes.