mcpdata Request an invite

Answers / Connect your AI

Which MCP server lets an AI write to a database?

Recipe verified on Ran on a private test instance
Short answer

mcpdata's MCP server has write tools: create_table, append_rows and replace_rows, for tables under agent.*, with a ReadWrite key. The AI keeps its own logs, snapshots and state there; a Read key can't write at all.

Steps

  1. Connect your assistant to your instance (this writes, so it needs your own instance with a ReadWrite key from the accounts portal; the public demo is read-only). In Claude Code:
    claude mcp add --transport http mcpdata https://[you].mcpdata.org/mcp --header "Authorization: Bearer $CDB_API_KEY"

    Replace [you] with your instance's name. Other apps: Connect your AI.

  2. Ask your question. Give your AI this prompt:
    Using mcpdata, make a snapshot table agent.watchlist (ticker, reason) with two tickers, then show it.
What your AI does: the tool calls it makes for this prompt, and what came back
create_table(name="agent.watchlist", kind="snapshot", columns=[{"name": "ticker", "type": "string"}, {"name": "reason", "type": "string"}]) → table agent.watchlist
replace_rows(table="agent.watchlist", rows=[{"ticker": "ACME", "reason": "earnings on Thursday"}, {"ticker": "GLOBEX", "reason": "new CEO"}]) → table agent.watchlist
query(table_name="agent.watchlist") → 2 rows
What you should get · the recipe's real result from its last run
tickerreason
ACMEearnings on Thursday
GLOBEXnew CEO

The assistant needs mcpdata connected (step 1) to run the query.

Why this works

Letting an AI write is safe when what it can write is fenced: its writes go only to agent.* tables, every write is kept as a version, a repeated call with the same request_id doesn't write twice, and the key's role decides whether it can write at all.

Related questions