MCP server

Let your agent drivethe Dynomatic you have open.

Dynomatic runs a Model Context Protocol server inside the app. Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, Zed, Codex, or any other MCP client connects to it and works through the connections, SSO and MFA sessions, and plan you already have. It listens on 127.0.0.1 only, behind a bearer token, and it is read-only until you say otherwise.

Read-only until you say otherwise. Two switches set a three-rung ladder. Out of the box an agent can read anything the app can read, and every write is refused. Allow writes admits writes to tables the environment classifier calls staging or development. Allow production writes admits the rest, including tables nobody has classified, because an unknown environment is not evidence that a table is safe. A line under the switches says what the current setting means, so nobody has to work it out from two checkboxes. See environment safety →

One registration, in each client's own shape. Pick the client and Dynomatic shows the registration its documentation asks for, filled in with the path of the build you are running: a claude mcp add command for Claude Code, JSON for Cursor, VS Code, Windsurf, Zed, and Claude Desktop, and TOML for Codex. It runs Dynomatic as a command, so you register it once and leave it. With the app closed the client still connects, and when you open Dynomatic and switch the server on, the tools appear on the connection it already has.

What an agent does, you can see. Connected clients lists every session with the name and version the client reported, the calls it ran, and the calls the server refused. An export an agent starts lands in the footer pill and the Transfers panel like one you started, with the same counters and the same Resume and Discard. When an agent wants to show you something, it opens the table in a new tab with its query filled in, and waits for you to press Run. See export →

What an agent can reach

01Your tables

List profiles and tables, describe a schema, query, scan, get one item or up to a hundred by key, and run PartiQL. A SELECT is a read. INSERT, UPDATE, and DELETE go through the same production check as every other write.

02Writes, on your terms

Create and delete tables, put, update, and delete items, and write up to 500 in one batch. Each write takes the path your own does, and a tab open on that table re-runs its query so the row appears.

03Scripts and variables

Run a TypeScript or Python script in the sandbox, one at a time, and resolve a template against the variables for a profile, region, and table to see what a query will actually send.

04What Dynomatic has learned

Read the schema profile, the data model the Data model tab shows, and the environment report, so an agent knows which writes will be refused before it tries one.

05Search by meaning

Search a table with a vector index in plain language, with the index, distance function, and model beside the ranking. Embedding the question waits for consent you give in the app, never the agent.

06Every command, classified

List every command the window calls and run the ones marked runnable, under the same permissions. Editing profiles, the keychain, a table's classification, and the server's own settings are held back.

Loopback onlyThe server binds 127.0.0.1, behind a bearer token.
Your sessions, your planEvery call re-checks the gates, so an agent gets what you get.
Never presses RunShowing a table fills the query builder and waits for you.
Pro, and open in Sample ModeTry it without a subscription and without AWS.

Your agent, your permissions,your app.