What the MCP server is

Dynomatic runs a Model Context Protocol server inside the app window. An MCP client connects to it and gets tools for listing profiles, describing tables, running queries, writing items, running scripts, exporting data, and opening a table in front of you. Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, Zed and Codex all connect, and so does anything else that speaks the protocol.

The server is off until you turn it on. It requires the Pro plan, and every gate is lifted in Sample mode, so you can try the whole thing without a subscription and without AWS.

An agent works through the app, not around it

The server is part of the running app rather than a separate process with its own credentials. Everything an agent does goes down the same path your own clicks do, which has four consequences worth knowing before you turn it on.

• It uses the profiles you have connected. An agent names a profile by the name list_profiles returns, and Dynomatic resolves it. There is no way to hand a tool call an access key or a role ARN.
• It inherits your live sessions. If you signed in through IAM Identity Center or answered an MFA prompt in the app, the agent’s calls use that session. If the session has expired, the agent’s call fails the way your own would, and only you can answer the prompt.
• It inherits your plan. Every call re-checks the mcpServer gate and the tool’s own gate, so an agent gets your entitlements and nothing more.
• It inherits Sample mode. While a sample session is running, an agent sees the sample tables and nothing else, because that is the only workspace the app has.

Read-only until you say otherwise

Permissions are a three-rung ladder, set by two switches in Settings.

1. Read-only is the default. An agent can read anything the app can read. Every write is refused.
2. Allow writes admits writes to targets the environment classifier calls staging or development.
3. Allow production writes admits the rest, meaning targets classified production and targets Dynomatic could not classify at all.

A refused call comes back with a refusal object naming which switch lifts it, so an agent can tell you what to change rather than retrying blindly. Permissions and refusals covers every refusal.

What it is not

• There is no cloud relay. The server binds 127.0.0.1 and nothing else, so it is reachable from your own machine and not from your network.
• No credential ever leaves the machine, and none reaches the agent. The commands that read, write or refresh credentials are withheld from the protocol outright, along with the ones that would let an agent change its own permissions. Any command, through one tool lists what is held back and why.
• The access token is not part of your settings record and is never written to the app log.
• An agent cannot run a query on your behalf and bill you for it silently. show_table fills a query into the query builder and waits for you to press Run.

See it working first

If you would rather read a transcript than a reference, Worked examples has eleven of them. Each one gives the question a person asked, the call the agent made, and the answer Dynomatic gave back, captured against the Sample mode tables. Every write attempted in them is refused, because the server was read-only, which is what you get out of the box.

Where to go next

• The MCP Server settings pane covers the Settings section, the token, and the limits the server enforces.
• Connect a client has the registration for each client, with config paths per operating system.
• Tools reference lists every tool with its effect and its plan gate.
• Worked examples shows most of them in use, with real requests and real answers.
• Exports and show in the app covers background exports and the two tools that open a tab.
• Troubleshooting starts with the most common symptom, which is a client that lists no tools.