AI & agents — Ask DynoStudio, Agent mode, MCP Gateway

View .md

Ask DynoStudio turns plain English into a PartiQL draft you review and run from the editor. Agent mode investigates questions such as “why is this export slow?” and proposes reads, indexes, or models for your approval. The MCP Gateway connects Claude Code, Cursor, or another MCP client to your table context and query tools. Connected clients can execute SELECT queries after obtaining an analyzer-issued plan, within the gateway’s session limits.

Turn it on

  • Settings → AI & agents — one switch for this user on this machine. It is deliberately not a workspace setting: “do not send my data to a model” is a statement about you, not about a workspace someone else may also open.
  • Pick a provider — Bedrock runs under the active stage’s own AWS identity and region (default us-east-1), with the model’s price read from the public AWS price list and shown beside the picker. Local talks to an OpenAI-compatible server on this machine — Ollama, LM Studio and vLLM are auto-detected on their default loopback ports — so no prompt leaves it. There is no bundled key and no Kanject-hosted inference.
  • Pick a model — the Bedrock roster is discovered from your account; Amazon Nova 2 Lite is the default because it needs no third-party model-access form. Any Bedrock model id can be typed in. Embeddings for EMBED() and re-embed jobs use Amazon Titan Text v2 by default, with Titan v1 and Cohere Embed v3 (English or multilingual) as alternatives.

The disclaimer the app shows on every AI surface applies here too: AI can make mistakes — check queries and answers before you rely on them.

Ask DynoStudio

Describe what you need and get an analyzer-checked draft. The composer builds its prompt from schema and access patterns; the model drafts a PartiQL statement; the same analyzer that checks your own statements checks the draft against the connected descriptor. The result card shows analyzer facts — Query or Scan, which index, what it reads — never model narration.

  • Four entry points, one gate — the standalone PartiQL console, a table’s Browse lens, the Board, and ⌘K (“Ask DynoStudio”).
  • Insert, never Run — the card’s terminal action is Insert into editor. There is no Run action on the card by design: running is your keystroke, through the normal “Executes as” disclosure.
  • No row data — row values are absent from the prompt by construction, not by a flag defaulting to off. Every draft asserts the No row data chip, and View exact AI payload shows the wire verbatim: what the UI reveals and what is sent are the same object.

Agent mode

State an objective — why is this export slow, which index would serve this access pattern, what should this model look like — and the agent investigates. It works through a closed vocabulary of actions that the studio dispatches — the model never invokes a tool itself — and proposes; you approve.

Inspect
Schema, access patterns, design notes, table health, usage, CloudWatch metrics, the current model and the table list.
Explain & compare
Explain a query the way the “Executes as” strip does; compare candidate plans without minting a runnable one — comparing is not choosing.
Propose
A governed read, an index (DDL text for your own gated surface), a table, or a whole replacement model staged as an uncommitted overlay on the Model face until you Apply.
Consult
The AWS Labs DynamoDB modelling expert, pinned to a version and asked only for reference guidance — DynoStudio passes it no table data, schema or query text.
  • Investigation depth — Low, Medium or High beside the model picker sets the budget one objective may spend. Six meters show it live: rounds, model calls, actions, active time, tokens in and tokens out. (Depth changes budgets, not the model’s own reasoning — the ledger says so.)
  • Rows — off by default per stage. Granting rows lets the agent request a bounded sample, and running that sample still needs your approval.
  • Next questions — a ranked, dismissible strip of suggested follow-ups above the composer, drawn from your own workspace. Model re-ranking of the deck is opt-in and capped.
  • Dock faces — Browse, Query and Model open inside Agent mode, so evidence and proposal sit side by side.

MCP Gateway

Turn on Serve local agents and DynoStudio hosts a Model Context Protocol server on this machine that exposes the studio’s deterministic capabilities — never a raw DynamoDB connection. It binds to loopback only, issues a per-session bearer token shown exactly once, and is off by default.

text 
get_schema            list_tables          get_modelget_model_diagram     propose_model        get_design_notesget_access_patterns   inspect_table_health inspect_usageinspect_metrics       preview_write        execute_writeverify_write_outcome  plan_bulk_operation  explain_queryrun_query             lookup_kanject_index

Five guarantees are rendered in Settings and are not configurable, by design — they bound what a mistake can do, not whether one happens:

text 
Explain before run   execution needs a plan the analyzer issuedSELECT only          writes and DDL are refused before dispatchStage pinned         changing tabs never retargets a connected agentRows off by default  granted explicitly, per sessionEvery call journaled tool, stage, outcome and cost stay on this machine
  • Gateway console — one click runs a wall-by-wall transport self-test of the endpoint; one more prints the exact connection snippet for the client you run (Claude Code, Cursor, or plain curl).
  • Journal — every call records tool, stage, outcome and cost, with no bearer token, credential or row data on the record.
  • Egress caps — a session’s reads are bounded by row count, bytes, RCU and time; a VECTOR_DISTANCE search is refused through the gateway today.

What the model sees

  • Ask DynoStudio — schema and access patterns. Row data is absent by construction; the exact payload is inspectable.
  • Agent mode — schema, access patterns, design notes and row-free runtime statistics (capacity, latency, CloudWatch digests). A row sample only with the per-stage grant and your approval, and it is capped.
  • Re-embed jobs — send row values selected by an explicit, user-authored recipe ({Title}\n{Description}) to an embedding model one item per call, never batched or chunked. Query history stores a digest of a query vector, never the floats.
  • DynoStudio’s model provider — a local model keeps prompts on your machine. Bedrock uses your account, region, and stage identity. Connected MCP clients use their own model configuration.
  • Switch off — every AI entry point is refused and nothing is sent, in every edition.

Editions

  • Community — carries the AI & agents switch (a privacy control has to exist at every edition) but not the AI surfaces; the Ask and Agent entry points offer the Professional upgrade.
  • Professional, Business, Enterprise — Ask DynoStudio, Agent mode, the MCP Gateway, the Gateway console and the DynamoDB expert. For Ask and Agent mode, bring your own Bedrock access or local model. AWS bills Bedrock usage separately; local inference has no per-request provider fee.

Related: Vector similarity search · CREATE / DROP VECTOR INDEX · Targeted reads · Tables, indexes & replicas.

Was this page helpful?