One MCP entry, every SQL Server you administer. Connections live in a single
connections.json, grouped by client or environment, hot-reloaded without
restarting your AI agent — plus execution plans, index audits and
stored-procedure analysis.
Built for DBAs and consultants, not for a demo against a single localhost database.
Add this to your AI agent's MCP configuration:
{
"mcpServers": {
"sqlserver": {
"command": "npx",
"args": ["-y", "@cevelas/mcp-sqlserver"]
}
}
}Then create your connections file and restart the agent:
npx -y @cevelas/mcp-sqlserver --initThat writes ~/.mcp-sqlserver/connections.json from a commented template. Edit
it, and ask your agent to "list all SQL Server connections".
Agent | Config file |
Claude Desktop (Windows) |
|
Claude Desktop (macOS) |
|
Claude Code |
|
VS Code / Copilot |
|
Cursor |
|
Any MCP-compatible agent works — ChatGPT, Gemini, Copilot, Cline, Zed and
others all take the same command / args pair.
Related MCP server: MySQL MCP Server
Most SQL Server MCP servers take a single connection string. That is fine for one database. It falls apart when you administer thirty across eight clients, because every instance needs its own entry in the agent config, its own credentials, and its own restart when something changes.
Single-DSN servers | This one | |
Instances per MCP entry | 1 | all of them |
Organised by client or environment | — |
|
Add or change a connection | edit agent config, restart | edit a file, |
Which server answered? | you assume | in every response's |
Beyond | — | execution plans, index layout, SP source |
Read-only safety rail | — |
|
{
"connections": [
{
"name": "acme-prod",
"connectionGroup": "Acme Corp",
"description": "Production - head office",
"server": "192.168.1.10\\SQLEXPRESS",
"database": "AcmeDB_Prod",
"user": "app_reader",
"password": "${env:ACME_PROD_PASSWORD}",
"port": 1433,
"encrypt": true,
"trustServerCertificate": false,
"readOnly": true
}
]
}Field | Required | Notes |
| yes | Unique; this is what you say to the agent |
| yes | Hostname, IP, or |
| no | Client, project or environment. Groups the listing |
| no | Shown in |
| no | Defaults to the login's default database |
| no | Omit for domain or Entra ID auth |
| no | Defaults to 1433 |
| no |
|
| no | Rejects writing statements — see below |
Anything else you put here is passed straight to mssql,
so requestTimeout, connectionTimeout, pool, authentication and a nested
options object all work.
Any string may reference an environment variable:
"password": "${env:ACME_PROD_PASSWORD}"A connection that references a variable you have not set is disabled, and
list_connections names both the connection and the missing variable. Leaving
the literal in place would only move the failure to connect time, where it
arrives as Login failed for user and tells you nothing.
You can also skip the file entirely and pass the whole thing through the agent config, which keeps credentials in one place with the rest of your MCP secrets:
{
"mcpServers": {
"sqlserver": {
"command": "npx",
"args": ["-y", "@cevelas/mcp-sqlserver"],
"env": {
"MSSQL_MCP_CONNECTIONS_JSON": "{\"connections\":[{\"name\":\"prod\",\"server\":\"10.0.0.1\",\"database\":\"App\",\"user\":\"reader\",\"password\":\"...\"}]}"
}
}
}
}In order, first hit wins:
--connections <path>
$MSSQL_MCP_CONNECTIONS — a path
$MSSQL_MCP_CONNECTIONS_JSON — the JSON itself, inline
./connections.json in the working directory
~/.mcp-sqlserver/connections.json
connections.json next to the installed package
A path given explicitly via 1 or 2 that does not exist is an error — the server will not quietly fall back to a different file and talk to the wrong database.
The bundled tedious driver supports NTLM and the Entra ID (Azure AD) family.
Add domain for NTLM:
{
"name": "warehouse",
"server": "dwh.corp.local",
"database": "DWH",
"domain": "CORP",
"user": "svc_analytics",
"password": "${env:DWH_PASSWORD}"
}{
"name": "azure-sql",
"server": "myserver.database.windows.net",
"database": "reporting",
"encrypt": true,
"authentication": {
"type": "azure-active-directory-password",
"options": { "userName": "${env:AZURE_USER}", "password": "${env:AZURE_PASSWORD}" }
}
}Fully integrated auth — a trusted connection with no password at all — needs
the native msnodesqlv8 driver, which is not bundled because it would break
the one-line install on machines without a build toolchain. NTLM with an
explicit service account is the supported path.
Tool | Arguments | What it does |
| — | Every connection, grouped |
| — | Re-read the file, drop open pools |
|
| Run a query |
|
| Columns, types, nullability, defaults |
|
| Indexes, types, key and included columns |
|
|
|
|
| Source of a stored procedure |
Every response carries the connection it came from:
{
"metadata": {
"connection": "acme-prod",
"connectionGroup": "Acme Corp",
"description": "Production - head office",
"server": "192.168.1.10\\SQLEXPRESS",
"database": "AcmeDB_Prod"
},
"data": [ ... ]
}With thirty connections in play, that line is what tells you the answer came from the client you meant.
Things that are tedious by hand and become one sentence to the agent:
"Why is this stored procedure slow?" — get_stored_procedure for the
source, get_execution_plan for the plan, get_indexes for what is missing.
"Compare the Orders schema between acme-prod and acme-qa" — get_schema on
both, agent diffs them.
"Which indexes on this table are never covering anything?" — get_indexes
plus the queries you care about.
"I added a client to connections.json" — reload_connections, no restart.
"readOnly": trueRejects INSERT, UPDATE, DELETE, MERGE, DROP, TRUNCATE, ALTER,
CREATE, GRANT, EXEC, BACKUP, DBCC, OPENQUERY, DISABLE/ENABLE
and friends before the query leaves your machine. It also requires the batch to
start with something that reads — SELECT, WITH, DECLARE, SET, IF
and so on — because T-SQL lets you call a procedure without EXEC, and
sp_rename 'dbo.Users','Users_old' contains no blocked keyword at all.
String literals, comments and bracketed identifiers are ignored, so
WHERE note = 'please delete this', SELECT [delete] FROM [Audit] and
DECLARE @Create DATETIME all pass. get_execution_plan still works, because
SHOWPLAN_XML returns the plan without executing anything.
Anything other than an explicit false turns the guard on — a hand-written
"readOnly": "false" locks the connection down rather than silently opening
it, and says so in list_connections.
This is a guard rail, not a security boundary. It stops an agent from
"helpfully" fixing a row in production. It will not stop someone determined to
write. The real protection is a SQL login that only has db_datareader:
CREATE LOGIN mcp_reader WITH PASSWORD = '...';
CREATE USER mcp_reader FOR LOGIN mcp_reader;
ALTER ROLE db_datareader ADD MEMBER mcp_reader;
GRANT VIEW DEFINITION TO mcp_reader; -- for get_stored_procedure
GRANT SHOWPLAN TO mcp_reader; -- for get_execution_planUse both.
connections.json holds credentials. Keep it out of version control — the
bundled .gitignore covers connections*.json.
Prefer ${env:VAR} over literal passwords.
Give each connection the least privilege it needs. Do not use sa.
Restrict file permissions:
icacls connections.json /inheritance:r /grant:r "%USERNAME%:F" on Windows,
chmod 600 connections.json elsewhere.
The query tool runs whatever SQL the agent writes. That is the point of the
tool — treat the connection's permissions as the boundary, not the tool.
web/connections.html is a standalone page for editing connections.json
without hand-writing JSON: drag and drop between groups, duplicate a
connection, autocompleting group selector, and auto-save through the File
System Access API in Chrome and Edge. No build, no dependencies, entirely
optional. See web/README.md.
Grab the .mcpb bundle from the
latest release
and drag it onto Claude Desktop's extensions settings. It will ask for the path
to your connections.json and wire everything up.
Your existing connections.json works unchanged — every new field is optional
and the tools take the same arguments. Two things worth knowing:
Multi-connection was broken before 3.0. The server used the mssql
global connection pool, which ignores the config it is handed once a
connection is already open. In practice every connection after the first
silently reused the first one's server and database. If you were relying on
results from more than one connection in a session, they may not have come
from where you thought. Fixed in 3.0 with a pool per connection.
If your agent config points at node C:\path\to\index.js, that still works.
The file resolution order now checks that path last, so nothing moves.
npm install
npm test # unit tests, no database needed
node .github/scripts/smoke.mjs # packs, installs and speaks MCP to the tarballAgainst a real server, name a connection from your own file:
MSSQL_TEST_CONNECTION=local npm run test:integrationThe mssql driver is injected, so the unit tests mock only that boundary —
everything else is the real code path. test/contract.test.js freezes the tool
names and arguments so a refactor cannot change the MCP surface by accident.
MIT — see LICENSE.
Christian Velasquez — @cvelasquez
Get execution plan for a query
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to analyze | |
| connection | Yes | Connection name to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only repeats the tool's purpose and does not state whether the query is actually executed, whether this is read-only, whether permissions are needed, or what side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant phrases. It is front-loaded and appropriately sized for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers the parameters, but with no annotations and no output schema, the description should provide some context about what the execution plan output looks like or how to interpret it. The description does not explain return values, limitations, or anything beyond the bare operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'sql' and 'connection' already described in the schema. The tool description adds no further parameter detail, but none is strictly needed because the schema already documents both parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('execution plan') and clarifies that it applies to a query. It clearly identifies the tool's core function, though it does not explicitly contrast it with sibling tools like 'query' or 'get_schema'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied: the phrase 'execution plan' suggests this tool is for analyzing a query's plan rather than executing it, and the sibling 'query' likely runs the query. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get index information for a table
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name | |
| connection | Yes | Connection name to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description does not mention permission requirements, error behavior, or what the returned index information will contain. This is a meaningful gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler words, and the core action is front-loaded. However, it is slightly under-specified—'index information' is vague enough that a brief clarification of the output would make it more appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter tool with fully documented schema fields, so the baseline requirement is fairly low. There is no output schema and no annotations, so the description should ideally clarify what 'index information' includes; the current phrasing is adequate but leaves return-value details to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both connection and table. The description adds no extra meaning beyond the schema; it mentions 'table' in prose but does not clarify formats, defaults, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('index information for a table'), immediately distinguishing it from sibling tools like get_schema or get_stored_procedure. It does not explicitly contrast itself with those siblings, but the resource is specific enough for an agent to understand what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as query or get_schema. No context is given about prerequisites, typical use cases, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get database schema information for specific tables
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Table name (optional, returns all if not specified) | |
| connection | Yes | Connection name to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves schema information but doesn't disclose whether it's read-only, whether it requires special permissions, what happens if the table doesn't exist, or whether it returns a large result set. For a read-like tool, the lack of behavioral context is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the main action and resource. It earns its place without redundancy, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no nested objects), the description is mostly adequate. However, it lacks context about what 'schema information' includes (e.g., columns, types, constraints) and doesn't mention behavior for invalid inputs or connection failures, which an agent might need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds minimal meaning beyond the schema, only implying that 'table' is optional and scopes the result. This meets the baseline of 3 but doesn't add extra context like format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('database schema information') and mentions it is for specific tables, which distinguishes it from siblings like query or get_indexes. However, it doesn't explicitly differentiate from get_indexes or get_stored_procedure, which are also schema-related, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving schema information, and the optional 'table' parameter suggests when to use it (for specific tables vs all). However, it doesn't explicitly state when to use this tool versus alternatives like get_indexes or get_execution_plan, nor does it mention any exclusions or prerequisites like needing a valid connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stored procedure definition
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Stored procedure name | |
| connection | Yes | Connection name to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It implies a read-only retrieval but does not disclose the exact return format, whether the definition includes the full CREATE statement, or how errors for non-existent procedures are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no wasted words. It lacks richer structure, but for a simple getter tool it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify the return value and usage context. It only states 'definition' without specifying the format or how it relates to sibling tools like get_schema, leaving an agent uncertain about when to choose this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema ('Stored procedure name' and 'Connection name to use'). The description adds no additional semantic detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and the specific resource 'stored procedure definition', making the tool's purpose immediately understandable. It does not explicitly differentiate from sibling metadata tools like get_schema or get_indexes, but the resource type is distinct enough to infer the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives such as get_schema or get_execution_plan. There is no mention of prerequisites like requiring a loaded connection, nor any exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available SQL Server connections grouped by connectionGroup
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It indicates a read-only listing operation and grouping, but does not disclose whether the list is fresh or cached, whether it reflects the same state as reload_connections, or what happens when no connections exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the core action and resource. Every part of the description carries meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, the description is adequate but leaves some context gaps. It does not clarify what connectionGroup means, whether the list is live or cached, or how this relates to the sibling reload_connections. No output schema further increases the need for a little more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds the 'connectionGroup' grouping concept, which is helpful even though it is not a parameter. There are no parameter semantics to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List all available SQL Server connections') and adds the grouping detail by connectionGroup. It is not a tautology and differs from siblings like reload_connections or query, though it does not explicitly name a sibling for contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool instead of reload_connections, whether it returns cached connection state, or what prerequisite actions (such as reloading) might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SQL query on the database
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute | |
| connection | Yes | Connection name to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, permissions, result format, or side-effect potential of executing arbitrary SQL. It only says 'execute a SQL query' and none of that is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is economical but it mostly restates the tool name and adds nothing of substance. No wasted words, but also no structured detail to help selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, a two-parameter query tool needs more context: supported SQL, side effects, result/return behavior. The description is too skeletal for an agent to predict consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both params have descriptions. The tool description adds no meaning beyond the schema, but the baseline 3 applies since the schema already provides adequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a clear verb-resource pair: 'execute a SQL query on the database.' It is somewhat generic but distinct enough from sibling tools like list_connections or get_execution_plan, which involve different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings or what types of queries are appropriate (SELECT only vs DDL/DML). It merely restates the operation without exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload connections from connections.json file without restarting the MCP server. Closes existing connection pools and loads new configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the important side effect that existing connection pools are closed and new configuration is loaded, which is meaningful behavioral context. However, it does not mention failure behavior, whether active queries are disrupted, or what happens if connections.json is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action and the key side effect are both front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless administrative action, this is nearly complete: it names the source file, the side effect, and the restart-free benefit. It could add failure-mode or validation details, but nothing critical is missing for an agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so there is nothing to document. The description usefully names the source file 'connections.json', which adds operational context beyond the schema. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Reload') and resource ('connections from connections.json file') and clarifies it happens without restarting the MCP server. This clearly distinguishes it from sibling read/query tools like list_connections and query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without restarting the MCP server' conveys the key scenario: applying configuration changes dynamically. It does not explicitly name alternatives or exclusion criteria, but the intent is clear enough for an agent to recognize when reloading is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v3.0.0get_execution_planget_indexesget_schemaget_stored_procedurelist_connectionsqueryreload_connectionsScored across 7 tools
Each tool targets a distinct concern: connection management, query execution, schema inspection, index inspection, execution plans, and stored procedure definitions. The purposes are clearly separated with no meaningful overlap.
Most tools follow a consistent verb_noun pattern like list_connections, get_schema, and get_indexes. The bare 'query' deviates slightly but is understandable and not confusing.
Seven tools is well-scoped for a SQL Server MCP server, covering connection management and common database inspection operations without unnecessary bloat.
The tool surface covers connection management, query execution, schema, index, execution plan, and stored procedure access. A minor gap is the lack of explicit listing tools for tables or procedures, but these can be queried through the query tool.
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Generate, fix, explain and run read-only SQL on PostgreSQL, MySQL and SQL Server
Draxlr's remote MCP server connects AI assistants to your SQL databases and dashboards. Explore schemas, run read-only queries, manage saved queries and dashboards, and export results, all with row-level security so each user sees only their own data.
DBRE-grade SQL analysis inside any MCP client. No connection. No install. Paste a query.
