This server provides a Model Context Protocol (MCP) interface for safe, structured access to Microsoft SQL Server databases, allowing LLM agents to inspect schemas and perform CRUD operations. All queries are parameterized and validated against the live schema to prevent SQL injection, and all operations are logged.
list_tables: List all user tables in the database, with an optional schema name filter.
get_table_schema: Retrieve column names, data types, nullability, and defaults for a specific table.
read_table_rows: Query rows with optional column selection, WHERE filters (supporting operators like >=, =, etc.), ORDER BY (ASC/DESC), and LIMIT/OFFSET pagination.
create_table_records: Insert one or more rows, with column and value validation against the live schema.
update_table_records: Update rows matching specified filter conditions; returns the number of affected rows.
delete_table_records: Delete rows matching specified filter conditions; returns the number of affected rows.
It is designed to integrate with MCP clients like Claude Desktop or Claude Code, connecting via stdio.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-mssql list all tables in the database"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that gives LLM agents safe, structured access to Microsoft SQL Server: schema inspection plus row-level CRUD, every operation parameterized and logged.
Built because agents working against real business databases need more than "run this SQL string" — they need typed tools with predictable failure modes.
flowchart LR
A[MCP client<br/>Claude Desktop / Claude Code] -- stdio --> B[mcp-server-mssql]
B --> C[connection pool<br/>mssql driver]
C --> D[(SQL Server)]
B -. structured logs .-> E[logs/]The server connects to a single database configured via environment variables and exposes six tools. All queries are parameterized — table and column names are validated against the live schema before any statement runs, so an agent cannot inject through identifiers.
Related MCP server: MCP Databases Server
Tool | What it does |
| List all user tables in the configured database |
| Column names, types, nullability, and defaults for a table |
| Read rows with optional column selection, WHERE filters, ORDER BY, and LIMIT |
| Insert one or more rows (column/value validated against schema) |
| Update rows matching a filter; returns affected count |
| Delete rows matching a filter; returns affected count |
User: "Which customers signed up this month?"
Agent calls
list_tables→ findsCustomers→ callsget_table_schema {"table_name": "Customers"}→ seesCreatedAt datetime2→ callsread_table_rows {"table_name": "Customers", "filters": {"CreatedAt": {">=": "2026-07-01"}}, "limit": 50}→ answers with the rows.
Requires Node.js 18+ and network access to a SQL Server instance.
git clone https://github.com/TerraCo89/mcp-server-mssql.git
cd mcp-server-mssql
npm install
cp .env.example .env # fill in connection details
npm run buildVariable | Required | Notes |
| yes / no | Port defaults to 1433 |
| yes | SQL auth credentials |
| yes | Single database per server instance |
| no | TLS options |
| no |
|
{
"mcpServers": {
"mssql": {
"command": "node",
"args": ["/path/to/mcp-server-mssql/dist/server.js"],
"env": {
"MSSQL_HOST": "localhost",
"MSSQL_USER": "agent_reader",
"MSSQL_PASSWORD": "...",
"MSSQL_DATABASE": "MyDb"
}
}
}
}Tip: point it at a least-privilege SQL login — the server can only do what the login can.
npm run dev # ts-node with live reload
npm test # jest test suite (src/*.test.ts, tests/)
npm run build # emit dist/Docker: docker build -t mcp-server-mssql . then run with the same environment variables.
Gets the schema of a specific table
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Name of the table | |
| schema | No | Database schema name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the basic function. It does not disclose any behavioral traits like side effects, permissions, rate limits, or response format.
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, clear sentence with no wasted words, but it is somewhat under-specified for a complete tool definition.
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 no output schema, the description does not explain what the schema includes (e.g., columns, data types), leaving ambiguity about the return value. It is adequate but not fully complete.
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% with both parameters described, so the description adds no extra meaning beyond the input schema. The baseline of 3 applies.
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 the verb 'gets' and the resource 'schema of a specific table', which differentiates it from sibling tools 'list_tables' and 'read_table_rows'.
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 is provided on when to use this tool versus alternatives, such as when you need table names (list_tables) or row data (read_table_rows). The description offers no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all tables in the database
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Database schema name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose important behavioral traits such as potential performance impact (listing many tables), required permissions, or whether the list is exhaustive. It only states the basic read operation.
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, front-loaded sentence. It is concise but lacks any structural elements like bullet points or sections, though it serves its purpose efficiently.
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 absence of an output schema, the description should clarify what information is returned (e.g., table names only, or with metadata). The current description is incomplete for an agent to fully understand the tool's output.
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 parameter 'schema' is adequately described in the schema. The description adds no additional meaning beyond what the schema provides, meriting a baseline score.
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 the tool lists all tables in the database. It distinguishes from siblings by specifying the resource as 'tables', while siblings focus on schema or row-level 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 usage guidance is provided. The description does not indicate when to use this tool versus siblings like get_table_schema or read_table_rows, nor does it mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads rows from a table with optional filtering and pagination
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Name of the table | |
| columns | No | Columns to select (optional, defaults to all) | |
| filters | No | Filter conditions (optional) | |
| limit | No | Maximum number of rows to return (optional) | |
| offset | No | Number of rows to skip (optional) | |
| order_by | No | Ordering specification (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure, but it only states it reads rows and can filter/paginate. It omits details like read-only nature (implied by name but not stated), authorization requirements, rate limits, or response format.
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 sentence with 10 words, no redundancy, and front-loads the core action. Every word is impactful.
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 has 6 parameters with nested objects and no output schema, the description is too minimal. It fails to describe the return format, error handling, or limitations such as maximum rows per call, leaving significant gaps for the agent.
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%, so baseline is 3. The description mentions optional filtering and pagination, which matches parameters like filters, limit, offset, order_by, but adds no new detail beyond the schema descriptions.
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 the verb 'reads' and resource 'rows from a table', and mentions optional filtering and pagination, effectively differentiating it from siblings like get_table_schema and list_tables.
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 does not provide explicit guidance on when to use this tool versus alternatives. While the siblings are distinct, the lack of any usage context or exclusions leaves the agent to infer based on names alone.
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.
v0.1.0get_table_schemalist_tablesread_table_rowsScored across 3 tools
Each tool has a clearly distinct purpose: listing tables, getting schema, and reading rows. There is no ambiguity between them.
All tool names follow a consistent verb_noun snake_case pattern: list_tables, get_table_schema, read_table_rows.
With 3 tools, the server is slightly underpopulated but still reasonable for a focused read-only database schema and data access tool.
The server lacks essential database operations such as writing, updating, deleting rows, or running arbitrary SQL queries, making it incomplete for typical use cases.
PostgreSQL, MySQL, and SQL Server in one session. 26 read-only MCP tools for AI agents.
Let AI agents query data and act across all your business apps via MCP.
An agent-native database over MCP: shared, validated, structured records in every AI chat.
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.
