DynoTable

MCP server

Connect Claude Code, Cursor, VS Code, or Codex to DynoTable's local MCP server for DynamoDB tables and OpenSearch indices — how to enable it, the per-connection consent and scopes, and the security model.

The Model Context Protocol (MCP) is an open standard that lets AI agents talk to external tools and data sources. DynoTable can act as an MCP server, so an agent running in your terminal or editor (Claude Code, Cursor, Codex, and others) can work with your DynamoDB tables and OpenSearch indices directly, instead of you copying schemas and results back and forth into a chat. When connected, the agent gets a projection of the built-in assistant's gated toolkit (reading your schema, running queries and single-item reads, staging changes for review, opening views, and exporting) over a local, loopback-only HTTP endpoint. Read-only queries use the same index and key condition as the in-app visual filter; preview equivalent SDK code with the query builder before wiring a client. A few app-local tools stay in the app and are not exposed. The agent discovers your tables, queries them, and proposes edits without ever holding your AWS credentials. It is off by default. Turning it on, and every individual connection, is explicitly under your control. See Security below.

Tables and indices

Each connection binds one profile, and that profile's Engines setting decides what the agent sees: DynamoDB tables, OpenSearch indices, or both. A connection to a DynamoDB-only profile gets no index capabilities, and the other way round. With OpenSearch on, an agent can read an index's mapping, search it with Lucene or the query DSL, read documents, run a vector search, and run SQL that joins tables to indices. With a staging scope it can stage document changes and bulk edits of indices too. OpenSearch MCP server covers what each scope allows on an index.

Enable the server

Open Settings → MCP and turn it on. DynoTable starts a server bound to 127.0.0.1 (loopback only, never reachable from another machine) and shows the connect command for it. DynoTable's Settings → MCP pane: the DynamoDB MCP server running on a local loopback port, with the list of connected clients and their access levels.

Expose profiles

The server is on, but no agent can connect until you expose a profile. Open a profile's MCP section in Settings and turn on Expose via MCP. Each exposed profile gets its own connect command, so you can wire up one connection per profile (e.g. a dynotable-dev and a dynotable-prod), each hard-isolated to that profile's credentials and region. A connection only ever sees the data of the profile it's bound to. Both AWS-backed and local (DynamoDB-Local) profiles can be exposed. Exposing a local profile lets an agent drive your local seeded tables over MCP, which is handy for development. (Two local profiles on the same port share the same local database, so they see the same tables.) A DynoTable profile's MCP section with “Expose via MCP” turned on. The per-profile connect block shows the endpoint to add to your client.

Connect a client

DynoTable speaks MCP over streamable HTTP, so any MCP-capable agent can connect. Each exposed profile shows its own connect command in its MCP section. Copy it from there. The command points at http://127.0.0.1:/mcp?profile=: the ?profile= tells DynoTable which profile you want and pre-selects it in the approval prompt (it's only a hint; you still confirm). Using the profile slug in the server name (e.g. dynotable-prod) keeps two profiles' connections distinct. The examples below use prod as the slug; substitute your profile's slug and the real port from Settings. Claude CodeCursorVS CodeCodexOpenCode Run this in your project. It's the command from the profile's MCP section. The URL is quoted because zsh treats an unquoted ? as a glob: claude mcp add --transport http dynotable-prod "http://127.0.0.1:/mcp?profile=prod" Add the server to the global ~/.cursor/mcp.json, the file the profile's snippet names. The port belongs to your machine, so keep it out of the project file .cursor/mcp.json, which gets committed: { "mcpServers": { "dynotable-prod": { "url": "http://127.0.0.1:/mcp?profile=prod" } } } Run MCP: Open User Configuration and add it to your user mcp.json (Copilot agent mode), which every workspace sees. The profile's snippet points there too, not at .vscode/mcp.json, a workspace file you'd commit. VS Code's add-server flow lists that user file as deprecated, kept for compatibility, and prefers the portable ~/.copilot/mcp-config.json (servers under a top-level mcpServers key) for new servers; the user mcp.json still works: { "servers": { "dynotable-prod": { "type": "http", "url": "http://127.0.0.1:/mcp?profile=prod" } } } Add it to ~/.codex/config.toml: [mcp_servers.dynotable-prod] url = "http://127.0.0.1:/mcp?profile=prod" Add it under mcp in the global ~/.config/opencode/opencode.json, the file the profile's snippet names, not the project-root opencode.json: { "mcp": { "dynotable-prod": { "type": "remote", "url": "http://127.0.0.1:/mcp?profile=prod", "enabled": true } } } To connect a second profile, repeat with that profile's command (its own slug). After connecting, restart or reload the client so it picks up the new server.

Approve the connection

The first time a client connects, DynoTable shows a consent prompt inside the app. It names the connecting client, lets you pick which profile the connection binds (pre-selected from the ?profile= hint, limited to your exposed profiles), and asks you to grant a scope, or deny. Nothing is exposed until you approve. DynoTable's in-app MCP consent prompt: a connecting client requests access, and you grant one of three scopes or deny.

Scopes

A scope decides which tools the connection can see and use. They are cumulative: each tier includes the ones before it: Read only: read your schema and index mappings, run queries, SQL and index searches, and read items and documents. No changes. Read & stage: everything in Read only, plus staging changes and bulk edits of items or documents for you to review and commit (the agent never writes to DynamoDB or OpenSearch directly; it routes through staging). Staging a single item or document needs the DynoTable window open on that profile; a bulk edit doesn't. Full access: everything above, plus opening views, setting filters and index queries, and exporting results. Writes still go through staging: even at Full access the agent can't write to DynamoDB or OpenSearch directly. Scopes follow your license. Signed out, the server refuses connections; on the free read-only plan every connection is clamped to Read only and the Workbench and Smart Table tools are hidden, whatever scope you approved. The connection binds the profile you approve in the prompt. Its credentials and region are pinned for the life of the connection, so it reads (and stages writes to) exactly that profile's data. The client name in the prompt is self-reported by the connecting agent, so the profile and scope you approve are the real gate, not the name. If the approved profile uses MFA, the agent is asked for the one-time code directly in its own session, so there is no need to switch back to DynoTable. (Profiles that sign in through SSO still complete that sign-in in DynoTable.)

Manage connections

Every approved client is listed in Settings → MCP. Revoke any of them at any time — a revoked client is cut off on its next request. Un-exposing a profile immediately revokes its connections too. Turning the server off stops everything.

Security

Loopback only. The server binds 127.0.0.1; nothing off your machine can reach it. Off by default, approval per connection. No agent gets access until you enable the server and approve its connection at a scope you choose. Credentials stay local. Connections use your existing AWS profiles on this machine (Connect to AWS); credentials are never sent to the agent. One profile per connection. Each connection is pinned to the single profile you approved — it can never reach another profile's tables, indices or credentials. Writes go through review. Even at Full access, changes are staged for you to commit. The agent can't write to DynamoDB or OpenSearch on its own. Revocable. Revoke a client or turn the server off whenever you want.

---

Canonical: https://dynotable.com/docs/mcp Site map for agents: https://dynotable.com/llms.txt · Ask this site: https://dynotable.com/llms?query=