Let Your Agents Query the Database,
Read-Only Until You Say Otherwise
AgentsRoom manages your MySQL and MariaDB connections and gives your AI coding agents a way to run queries against them. Read-only by default, one statement at a time, with the password kept out of reach.
An agent that can read the real rows stops guessing about your data. An agent that cannot write to them stops being a risk you have to supervise line by line.
How AgentsRoom reaches a database in a private subnet and answers a read-only query from an AI agent.
An AI coding agent that cannot see your data writes code against the schema it imagined. It invents a column, assumes an enum has three values when it has seven, and explains a bug with a theory instead of a row. Giving it a database connection fixes that, and it is also the fastest way to turn a helpful agent into an incident. AgentsRoom is built around that tension.
You save your MySQL and MariaDB connections in the app the way you would in any SQL client : host, port, user, database, and TLS when the server expects it. If the database is not reachable from the open internet, the connection is routed through an SSH tunnel or an AWS SSM port-forwarding session, using the SSH and SSM connections you already saved in AgentsRoom. That is how a database sitting in a private subnet becomes something you can query without opening it to the world.
Every connection starts read-only. A SELECT runs. A statement that would modify data does not, until you have made that specific connection writable and confirmed the operation. Only one statement is accepted per call, so nothing extra hides behind a semicolon, and result sets are capped so a wide query cannot flood an agent or a window. A connection can also be flagged as production, which makes the confirmation harder to give by accident.
A SQL Client That Assumes an Agent Is Driving
MySQL and MariaDB, reachable in private networks, with the guardrails on by default.
MySQL and MariaDB Connections
Save a connection per database : host, port, user, the database to open and TLS when the server requires it. Your local database, the staging one and the production replica all live in the same list, ready to be picked instead of retyped.
Reach a Private Database
A database in a private subnet is not a special case. Route the connection through an SSH tunnel or an AWS SSM port-forwarding session and AgentsRoom opens it for you, reusing the SSH and SSM connections you already saved in the app.
Read-Only by Default
A new connection can read and nothing else. Queries return rows, statements that would change data are refused. Nobody has to remember to set the safe mode, because the safe mode is where every connection starts.
Two Locks Before a Write
Writing takes two deliberate acts, not one. The connection has to be made writable, and the operation itself has to be confirmed explicitly. A single careless click cannot chain into an UPDATE without a WHERE clause.
One Statement per Call
Each call carries exactly one statement. Anything stacked behind a semicolon is refused rather than executed, so a read that looks like a read cannot smuggle a second statement along with it. Result sets are capped on top of that.
Production Is Flagged
Mark a connection as production and the confirmation gets harder. The database that matters stops looking exactly like the local copy, both to you at the end of a long day and to an agent working through a task list.
Agents Query the Database, They Never Hold the Password
Your database credentials are stored by AgentsRoom, not handed out. An agent asks to run a query against a connection it knows by name, the app opens the connection, runs the statement and returns the rows. The password is never part of what the agent receives, never part of the query it writes, and never part of the conversation it keeps.
The read-only rule is the second half of that, and for an agent it is not a default it could talk its way out of. The tool an agent queries with refuses anything but a read, whatever that connection allows. Making a connection writable unlocks writes for you, in the SQL console, where each one asks for an explicit confirmation that is deliberately harder to give when the connection is flagged as production. The worst outcome of an agent running a bad query stays a wrong answer rather than a lost table.
The single-statement rule closes the classic gap. A call that carries one statement cannot be extended with a semicolon and a second one, so a query that reads as harmless in a review cannot do something else at execution time. Combined with capped result sets, a mistake stays a mistake instead of becoming an export.
MySQL and MariaDB today, and nothing else
The database client in AgentsRoom speaks the MySQL wire protocol, and MariaDB is compatible with it, so both are supported right now : directly, or through an SSH tunnel or an AWS SSM port-forwarding session when the server is not reachable from the open internet.
PostgreSQL, MongoDB, SQL Server, SQLite and the others are not supported. You deserve to know that before the download rather than after it. Which engine comes next is decided by what people ask for, so if yours is missing, say which one on the public backlog and it gets counted.
Request your database engineFrom a Private Database to an Answer
Save the connection, route it, then query it or let an agent do it.
Save the connection
Add the database : host, port, user, the database name, and TLS if the server expects it. Give it a name you will recognise later, and flag it as production if that is what it is.
Route it if it is private
If the database is not reachable directly, point the connection at an SSH tunnel or an AWS SSM port-forwarding session built from the connections already saved in AgentsRoom. A database in a private subnet becomes reachable without exposing it publicly.
Query it, or let an agent query it
Run your statement from the app, or let an agent run one over MCP. Read-only until you change it, one statement per call, capped result sets, and an explicit confirmation standing between any write and your data.
When an Agent Needs the Real Rows
The moments where reading production data is the shortest path to the fix.
Debug against real data
The bug only shows for a handful of accounts. Let the agent read those rows and it finds the value that breaks the logic, instead of proposing three theories about what the data might look like.
A database that is not public
The database lives in a private subnet with no public endpoint. Route the connection through an SSH tunnel or an AWS SSM session built on your saved connections, and query it without opening a port to the internet.
Let the agent check, not guess
Before it writes a migration or a query, an agent can look at what is actually stored. It reads, it reports, and it never gets the ability to change anything while it does.
Production, without the write risk
Reading production is often necessary, writing to it almost never is in the middle of a task. Flag the connection as production, keep it read-only, and the difference between investigating and breaking stops depending on anyone paying attention.
How do my agents query the database?
Through AgentsRoom MCP, with four tools. db_list returns your saved connections and their metadata, db_schema walks the schemas, the tables and the columns without a line of SQL, db_query runs one statement and returns the rows, and db_connection_new proposes a database you have not saved yet. AgentsRoom opens the connection, including the SSH tunnel or the AWS SSM session in front of it when there is one. What travels back to the agent is a result set, never a credential.
db_query is read-only whatever the connection allows. Making a connection writable unlocks writes for you, in the SQL console, where each one is confirmed explicitly and where a connection flagged as production says so out loud. It does not unlock them for an agent : the read-only rule for db_query lives in the desktop app rather than in the MCP process, so it holds even if the agent is talked into asking for something else. You do not need a password to run a DROP, which is why the guardrail sits on the statement and not only on the credential.
The same limit applies to registering a database. db_connection_new opens the creation form pre-filled with the host, the user and the SSH or AWS SSM connection it should be reached through, and you review it, type the password and save. Nothing is stored until you do. The agent gets what it needs to reason about your data, and none of the ways that access usually turns into an incident are available to it.
Discover AgentsRoom MCPFAQ
Which databases are supported?
MySQL and MariaDB, and only those. The client speaks the MySQL wire protocol and MariaDB is compatible with it, so both work, directly or through an SSH tunnel or an AWS SSM port-forwarding session. PostgreSQL, MongoDB, SQL Server, SQLite and the rest are not supported today. If you need one of them, ask for it on the public backlog : the list grows with what people actually request.
Can an AI agent write to my database?
No. The MCP tool an agent queries with, db_query, is read-only whatever the connection allows : SELECT, SHOW, DESCRIBE, EXPLAIN and WITH go through, anything that would change data is refused. Making a connection writable unlocks writes for you in the SQL console, where each one is confirmed explicitly, not for an agent. The guardrail sits on the statement rather than on the password, because a password is not what it takes to run a DROP.
How do I reach a database in a private subnet?
Route the connection through an SSH tunnel or an AWS SSM port-forwarding session, built from the SSH and SSM connections you already saved in AgentsRoom. The app opens the tunnel or the session and connects the database through it, so the database stays unreachable from the public internet.
Do my agents see the database password?
No. Agents query through MCP by naming a connection. AgentsRoom holds the credentials and runs the statement itself, so the password is never returned to the agent, never written into the query and never part of the conversation.
Can an agent run several statements at once?
No. One call carries exactly one statement. Anything stacked behind a semicolon is refused rather than executed, which removes the oldest way to hide a write inside something that looks like a read.
What does flagging a connection as production change?
It hardens the confirmation required before a write. The database that matters stops behaving like the local copy, which is what you want at the end of a long day and what you want even more from an agent working through a task list.
What happens with a query that returns a lot of rows?
Result sets are capped. A query that would return an enormous table comes back truncated instead of flooding the window or the agent context, so a wide SELECT stays an inconvenience rather than an export of your data.
Can an agent add a database connection?
It can propose one, never save one. db_connection_new opens the creation form pre-filled with the host, the port, the user and the SSH or AWS SSM connection the database should be reached through, and you review it, type the password and save. Nothing is stored until you do, and the agent never supplies a credential.
How does an agent learn my schema?
With db_schema, which explores a saved connection without any SQL. Called with no argument it lists the schemas, with a database it lists the tables and views, with a table it returns the columns, their types, their nullability, their keys and their defaults. It is cheaper and safer than making an agent query information_schema by hand.
You may also like
RDS through AWS SSM
Reach an Amazon RDS instance that has no public endpoint, from your own machine, through aws ssm start-session and the AWS-StartPortForwardingSessionToRemoteHost document. No bastion to maintain, no VPN, no inbound SSH rule. AgentsRoom opens the session on a loopback port and connects the SQL client through it. MySQL and MariaDB only, so RDS MySQL and Aurora MySQL-compatible.
SSH Connections
Save your SSH connections, open a built-in terminal over SSH, and run Claude Code, Codex or Antigravity CLI directly on your remote server or VPS. SSH key or password auth, per-project connection profiles, no separate SSH client needed.
Secret Manager
Store API keys, tokens and passwords in your OS keychain, reference them as {{secret:NAME}} in dev commands and agent environments, and let AgentsRoom resolve them at launch. Agents see the names, never the values, and nothing is ever synced to a server.
Dev Terminals
Per-project terminal manager and process launcher. Start backend, frontend and workers in one click, locally or on a remote server.
AgentsRoom MCP
The MCP server that lets your agents drive AgentsRoom itself : projects, terminals, backlog and connections, with the guardrails that come with it.
Give Your Agents the Data, Not the Keys
Download AgentsRoom, save your MySQL and MariaDB connections, reach them through an SSH tunnel or an AWS SSM session, and let your agents query them read-only.
Companion app: monitor your agents on the go
Bring your own: Claude, Codex, Antigravity CLI, or other AI provider.
Push bugs and requests straight to your public backlog.
A glimpse of AgentsRoom in action.