How do I use mssql-pyodbc-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mssql-pyodbc-mcp list all tables" 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.

mssql-pyodbc-mcp

by tsod

Overview Schema Source Related Servers Discussions Admin

Python

Local

mssql-pyodbc-mcp

Local stdio MCP server for read-only Microsoft SQL Server access through Python and pyodbc.

Features

test_connection: validates configuration and checks DB connectivity.
list_tables: lists accessible user tables.
describe_table: returns simple column metadata.
query: executes read-only SELECT queries and returns at most 100 rows.

The first release supports one configured MSSQL database and SQL username/password authentication only.

Related MCP server: SQL Query Tools MCP Server

Environment Variables

Required:

MSSQL_SERVER
MSSQL_DATABASE
MSSQL_USER
MSSQL_PASSWORD

Optional defaults:

MSSQL_DRIVER=ODBC Driver 18 for SQL Server
MSSQL_PORT=1433
MSSQL_TRUST_SERVER_CERTIFICATE=yes

The implementation sets Encrypt=no and passes TrustServerCertificate from the environment. For production-like environments, use a properly trusted server certificate and tighten encryption settings before exposing the server beyond local agent usage.

Some older SQL Server instances only support legacy TLS settings. If pyodbc fails with unsupported protocol, run the MCP server with:

export OPENSSL_CONF="$PWD/scripts/openssl-legacy.cnf"

Install

python -m venv .venv
. .venv/bin/activate
pip install -e ".[dev]"

You also need a Microsoft SQL Server ODBC driver installed on the host, such as ODBC Driver 18 for SQL Server.

Run

export MSSQL_SERVER=localhost
export MSSQL_DATABASE=MyDatabase
export MSSQL_USER=my_user
export MSSQL_PASSWORD=my_password
export MSSQL_DRIVER="ODBC Driver 18 for SQL Server"
export MSSQL_PORT=1433
export MSSQL_TRUST_SERVER_CERTIFICATE=yes
export OPENSSL_CONF="$PWD/scripts/openssl-legacy.cnf"

mssql-pyodbc-mcp

Live DB Checks

After exporting the environment variables, verify the local setup with:

python scripts/check_odbc_connection.py
python scripts/check_mcp_tools.py

Codex MCP Example

Configure your MCP client to run the command:

mssql-pyodbc-mcp

Pass the environment variables through your MCP client configuration or shell environment.

Safety Notes

The query tool accepts general SELECT and CTE-style read queries.
Mutating, schema-changing, administrative, EXEC, and multi-statement SQL are rejected by policy.
Query results are limited to 100 rows.
Use a read-only SQL Server account whenever possible.
Passwords and full connection strings are not returned in tool responses.

Tests

pytest

The unit tests do not require a live MSSQL instance.

Available Tools

4 tools

describe_tableA

Return column_name, data_type, and nullable for a table.

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must cover behavioral traits. It implies read-only behavior but does not explicitly state it is non-destructive or that it requires the table to exist. Minimal transparency for a simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence directly stating purpose. No wasted words; efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter tool with an output schema, the description tells what it returns. However, it omits context like error conditions (e.g., table not found) or that it is a read operation. Slightly incomplete but acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only parameter 'table_name' has no schema description (0% coverage). The description adds no additional meaning (e.g., format, case sensitivity, or that it must be an existing table).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns column metadata (column_name, data_type, nullable) for a table, which distinguishes it from sibling tools like list_tables (lists tables) and query (executes SQL).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternatives. Does not mention that list_tables provides table names or that query retrieves data. Lacks contextual cues for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesA

List accessible user tables in the configured MSSQL database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description indicates this is a read-only operation listing accessible tables, filtered by user permissions. It does not elaborate on response size, ordering, or potential delays, but the core behavior is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, informative sentence that concisely states the tool's purpose with no extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (no parameters, output schema exists), the description is complete. It specifies the scope (accessible, user tables, configured database) and leaves no critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100% (empty schema). The description correctly adds no parameter detail since none exist. According to the baseline for 0 params, a score of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the action (list), the resource (accessible user tables), and the context (configured MSSQL database). It clearly distinguishes from siblings like describe_table (which describes a single table) and query (which executes queries).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The implied usage is to discover available tables before using describe_table or query. However, there is no explicit guidance on when it should or should not be used, nor any mention of alternatives beyond the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

queryA

Execute a read-only SELECT query and return at most 100 rows.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses read-only nature and row limit, but does not specify error handling or behavior for non-SELECT statements. Since no annotations exist, the description carries the full burden but only partially addresses it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words, front-loaded with critical constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Low complexity and an output schema exist; description covers the essential behavior, though it could mention permissions or query validation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (sql) with 0% schema description coverage; the description adds no additional meaning or examples beyond the schema's type string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes a read-only SELECT query and returns up to 100 rows, distinguishing it from sibling tools like describe_table and list_tables which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for ad-hoc SELECT queries, but no explicit when-to-use or when-not-to-use compared to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_connectionA

Validate MSSQL environment configuration and test database connectivity.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

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. It states what the tool does but lacks details on the validation scope, failure behavior, or any side effects. The description is too vague to fully inform the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that efficiently conveys the tool's purpose with no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and the presence of an output schema, the description is minimally adequate. However, it lacks details about the environment configuration validation and assumes the agent understands what 'validate' entails. A bit more context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage, there is nothing additional to document. The description does not need to add parameter semantics, so the baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (validate and test) and the resource (MSSQL environment and database connectivity), and it is distinct from sibling tools (describe_table, list_tables, query) which focus on table metadata and data retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions. This is a gap for an AI agent deciding between tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Jun 23, 2026
- First observeddescribe_table
- First observedlist_tables
- First observedquery
- First observedtest_connection

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-06-23 09:25 across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: listing tables, describing a table's schema, executing a SELECT query, and testing connectivity. No overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun snake_case pattern (describe_table, list_tables, test_connection). The 'query' tool is a single verb but still clear and fits the general pattern.

Tool Count4/5

With 4 tools, the server covers essential read-only database operations. The count is slightly thin but appropriate for the focused scope of querying and exploring a MSSQL database.

Completeness3/5

The set covers connection testing, table listing, schema description, and querying. Missing tools for exploring views, stored procedures, or other metadata, which are minor gaps for a read-only server.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
SRI — MCP Server Inspector A
biz.sri-test
2,000+ MCP servers read at source level. Know what one does before you connect. Free, no key.
Developer Tools
21
mcp A
tools.clean
Read-only developer, date, finance, and text utilities. Authless remote MCP server by Clean.tools.
Developer Tools Finance
422
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292

Related MCP Servers

mcp-odbc
Databases Developer Tools
phil-cheesman
A
license
Not graded
quality
D
maintenance
A Python MCP server that connects to any ODBC data source and exposes schema discovery + query tools. Read-only by default, write access available per-connection.
Updated 7 months ago (2026-03-02 18:25 UTC)
2
MIT
SQL Query Tools MCP Server
Databases Security
negrip
F
license
A
quality
D
maintenance
MCP server for connecting to SQL Server in readonly mode. Allows any MCP client to explore the schema and run SELECT queries against a SQL Server database.
Updated 6 months ago (2026-04-01 20:52 UTC)
6
-
mcp-mssqlserver
Databases Developer Tools
ferronicardoso
A
license
A
quality
B
maintenance
Production-oriented MCP server for Microsoft SQL Server, enabling query execution, database discovery, schema introspection, and metadata inspection via MCP clients.
Updated a month ago (2026-08-18 18:43 UTC)
6
4
MIT
SQL Database Bridge
alizaimovic
A
license
Not graded
quality
A
maintenance
MCP server that connects to SQL databases (SQLite, PostgreSQL, MSSQL, MySQL) and provides tools to run read-only queries, list schemas/tables, and manage connections via stdio transport.
Updated 2 months ago (2026-07-22 07:37 UTC)
Apache 2.0