Browser tools (WebMCP)

The dashboard publishes a tool surface to agents running in the browser - no API key, no server to configure, every write approved by you.

What it is

WebMCP is a proposed web standard that lets a page hand an AI agent a set of typed tools instead of leaving it to guess its way around the interface. When you open the CapyDB dashboard in a browser that implements it, the page registers its own tools on document.modelContext, and an agent in that browser can work your databases directly.

Nothing to install, and nothing to configure. The tools run on the session you are already signed in with, so there is no API key to mint and no MCP server to add to a config file. That is the whole point of this path: the setup cost is zero because you have already done it by logging in.

This is the third way to give an agent access to CapyDB, alongside the CLI and the MCP server. Use whichever matches where your agent lives.

Availability

WebMCP is new and support is narrow. Today it reaches you through:

Chrome 149+, on origins enrolled in the WebMCP origin trial — the mechanism by which stable Chrome gets the API before it ships broadly.
Chrome with the testing flag on — chrome://flags/#enable-webmcp-testing. This is the path for trying it yourself today.
Agent browsers that embed WebMCP support, which at the time of writing includes ChatGPT's in-app browser.

If your browser has no WebMCP support, nothing changes and nothing breaks — the dashboard simply publishes no tools, and your agent should fall back to the CLI or MCP path.

The specification is a W3C Community Group draft under active revision, not a finished standard. Expect this surface to move.

Tools

Tools are scoped to the page that is open, and withdrawn when you navigate away. An agent can only act on the database you are actually looking at.

Available anywhere under /dashboard/<workspace>:

Tool	What it does
`list_projects`	Every database in the workspace with status, region, and Postgres version. No credentials.
`list_regions`	Regions a new database can be placed in.
`get_usage`	Workspace storage, connection, and database counts against plan limits.
`create_project`	Create a database. Needs your approval. Returns once the work is queued; the agent polls `list_projects` until it reads Ready.

Available only while a project page is open, acting on that database:

Tool	What it does
`get_project`	Status, region, Postgres version, and plan.
`get_schema`	The complete schema in one call — tables, columns, keys, enums, extensions.
`list_tables`	Tables and views by schema.
`get_table_rows`	Rows from one table.
`list_extensions`	Available extensions and whether each is enabled. Changing them happens in the dashboard.
`suggest_indexes`	Index suggestions from the queries the database actually ran. Read-only — nothing is created.
`find_unused_indexes`	Indexes with no recorded scans, or covered by a wider index, each with the drop statement to run. Read-only — nothing is dropped.
`run_sql`	Run a statement, up to 200 rows. Writes need your approval.
`list_preview_databases`	Preview databases with mode, state, and expiry.
`create_preview_database`	Create a disposable copy (`clone` or `empty`, optional TTL). Needs your approval.
`list_backups`	Backups with size and verification state.
`create_backup`	Queue an on-demand backup. Needs your approval.
`list_restore_points`	Named restore points that keep a pre-change state addressable.
`create_restore_point`	Pin a point-in-time marker before a risky change. Needs your approval. Recovering from one happens in the dashboard or CLI.
`list_alerts`	Open health alerts; resolved history on request.
`get_observability`	Live storage and connection usage against plan limits.
`get_logs`	Recent Postgres log entries, filterable by severity.
`list_jobs`	Recent background operations and whether each succeeded.
`get_job`	One background operation by id, with its report once complete.
`major_upgrade_preflight`	Check whether the database can move to a Postgres major, without changing anything.

What an agent cannot do here

An agent inside your browser is a weaker principal than an API key you deliberately created for it: you did not choose it, you cannot scope it, and you cannot revoke it separately from your own login. The surface is narrower than the MCP server's to match.

No credentials. Connection strings are never returned. Neither is creating API keys or reading webhook secrets. When an app needs credentials, they come from the Connections page, the CLI, or the MCP server.
Nothing irreversible. No deleting a database or a preview, no restores, no promoting a preview to production. Those live in the dashboard and the CLI, where a person is already driving.
Nothing outside the page. A project tool acts on the project whose page is open. To point an agent at a different database, open it.

Approving what an agent does

Every tool that changes something stops and asks you. A dialog names the tool and shows exactly what would happen — the SQL to be run, the database to be created — and nothing proceeds until you approve it.

Read-only queries do not interrupt you. A statement counts as read-only only if it both starts as a read and contains no write keyword anywhere, so WITH moved AS (DELETE FROM …) SELECT … asks, as it should. EXPLAIN ANALYZE also asks, because it executes the statement it explains.

Declining is safe and final: the agent is told you declined, and the call never reaches the database. Closing the dialog, cancelling the agent's request, or navigating away all count as declining.

Rows an agent reads are your data, and a determined attacker who can write to your tables can try to influence the agent through them. The tools that return database content are marked as untrusted for exactly this reason. Treat an agent working against a database full of user-generated content the way you would treat any other client of that data.

Working with it

The same habits that make the MCP server productive apply here.

Ask for get_schema before schema questions; it answers most of them without a query.
For risky work — a migration, a bulk update, anything destructive — have the agent pin the current state with create_restore_point first, then create a preview database and work there. Previews are copy-on-write clones with a TTL: create, break, throw away. See Previews and the agent safety loop.
After anything that queues work, list_jobs says whether it finished; get_job follows one operation.

An agent that wants the machine-readable version of this page can fetch capydb.dev/webmcp.md.