Run a SELECT-style SQL query against a configured database. The query executes inside a transaction that is ALWAYS rolled back, so accidental DML/DDL is non-durable (this is a guardrail, not a sandbox: an explicit COMMIT TRANSACTION in the query string ends the wrapper and following writes will p...
AI agents invoke execute_read_query to trigger actions in Mssql Mcp Node. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
dbKey | string | — | Database key (lowercased). Optional in single-database mode. Call `list_databases` to discover valid keys. |
limit | integer | — | Max rows to return (1..1000). |
query | string | Yes | Read-only SQL query. Wrapped in a rollback-only transaction, so any incidental writes are discarded. Results are streamed and the underlying request is cancelle |
offset | integer | — | Row offset for pagination. |
Parameters from the server's own tool schema.
Although intended for read-only SELECT queries, the tool executes arbitrary SQL inside a transaction that can be escaped via COMMIT TRANSACTION, allowing writes and DDL to persist. This makes it effectively an arbitrary SQL execution tool. The rollback is a soft guardrail, not true isolation, so the blast radius is high — a misused or injected query could cause destructive or write side effects.
From the tool's definition 'Run a SELECT-style SQL query' but 'an explicit `COMMIT TRANSACTION` in the query string ends the wrapper and following writes will persist' and 'accidental DML/DDL is non-durable (this is a guardrail, not a sandbox)'
Risk signalsAccepts freeform code/query input (query)
Attacks that exploit this kind of access
Run a SELECT-style SQL query against a configured database. The query executes inside a transaction that is ALWAYS rolled back, so accidental DML/DDL is non-durable (this is a guardrail, not a sandbox: an explicit COMMIT TRANSACTION in the query string ends the wrapper and following writes will persist - rely on a least-privilege SQL login for real isolation). Results are streamed; the server cancels the underlying request once offset + limit rows have been seen, so truncated:true means more rows exist. It is categorised as a Execute tool in the Mssql Mcp Node MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
execute_read_query accepts 4 parameters: dbKey, limit, query, offset. Required: query. The full parameter table on this page comes from the server's own tool schema.
Register the Mssql Mcp Node MCP server in PolicyLayer and add a rule for execute_read_query: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mssql Mcp Node. Nothing to install.
execute_read_query is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the execute_read_query rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for execute_read_query. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
execute_read_query is provided by the Mssql Mcp Node MCP server (mssql-mcp-node). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Every MCP server has a record like this.
Type a name, get the same breakdown: verified identity, auth posture, risk grade, capabilities, recommended policy.
Teams ship this data inside their own products. See what a licence covers →