Skip to main content
Glama
SerenaHangSinclair

MCP MS SQL Server

by SerenaHangSinclair
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

MCP MS SQL Server

A Model Context Protocol (MCP) server for Microsoft SQL Server that provides tools for database operations, data analysis, and visualization generation.

License: MIT Python 3.10+

Table of Contents

Related MCP server: MSSQL MCP Server

Features

8 Powerful Database Tools - Query execution, schema exploration, and data analysis
Interactive Visualizations - Bar charts, scatter plots, heatmaps, and more
Jupyter Notebook Generation - Automated analysis code creation
Power BI Integration - Export data in Power BI compatible formats
Security Controls - Granular permissions for write operations
Connection Pooling - Optimized performance with configurable pools

Quick Start

  1. Install the package

    pip install mcp-mssql-server

  2. Create configuration

    # Create .env file
DB_TYPE=mssql
MSSQL_SERVER=tcp:your-server.database.windows.net
MSSQL_USER=your-username
MSSQL_PASSWORD=your-password
MSSQL_DATABASE=your-database

  3. Run the server

    uv run python mssql.py
or
uv run python main.py

Installation

Option 1: Using pip

pip install mcp-mssql-server

Option 2: Using uv

uv pip install mcp-mssql-server

Option 3: From source

git clone https://github.com/SerenaHangSinclair/mcp-mssql-server.git
cd mcp-mssql-server
pip install -e .

Configuration

Create a .env file in your project root with the basic required settings:

# Database Connection (Required)
DB_TYPE=mssql
MSSQL_SERVER=tcp:your-server.database.windows.net
MSSQL_PORT=1433
MSSQL_USER=your-username
MSSQL_PASSWORD=your-password
MSSQL_DATABASE=your-database

# Security (Recommended)
ALLOW_WRITE_OPERATIONS=false
# Database Type (mssql)
DB_TYPE=mssql

# SQL Server Configuration
MSSQL_SERVER=tcp:your-server.database.windows.net
MSSQL_PORT=1433
MSSQL_USER=your-username
MSSQL_PASSWORD=your-password
MSSQL_DATABASE=your-database
MSSQL_ENCRYPT=true
MSSQL_TRUST_SERVER_CERTIFICATE=true

# Security Settings
ALLOW_WRITE_OPERATIONS=false
ALLOW_INSERT_OPERATION=false
ALLOW_UPDATE_OPERATION=false
ALLOW_DELETE_OPERATION=false

# Performance Settings
CONNECTION_POOL_MIN=1
CONNECTION_POOL_MAX=10
QUERY_TIMEOUT=30000

Usage

Running the MCP Server

Suggest to use uv to create a sperate virtual environment for the MCP construction. Remember to install uv/:

Windows

    powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

MacOS/Linux

    curl -LsSf https://astral.sh/uv/install.sh | sh
    uv venv

Running the MCP Server

Basic usage:

uv run python main.py or uv run python mssql.py

With logging enabled:

uv run python main.py --log

Using with Claude Desktop

Add this configuration to your Claude Desktop settings:

{
  "mcp-mssql-server": {
    "command": "uv",
    "args": ["run", "python", "/path/to/mcp-mssql-server/main.py"]
  }
}

Tools Overview

Tool

Purpose

Output

sql_query

Execute SQL queries with permission controls

Query results

get_database_info

Get server and database information

Server details

show_tables

List all tables in the database

Table list

describe_table

Get detailed table structure information

Column details

show_indexes

Display table indexes

Index information

generate_analysis_notebook

Create Jupyter notebooks for data analysis

.ipynb file

generate_visualization

Create interactive visualizations

.html file

generate_powerbi_visualization

Generate Power BI compatible exports

.csv/.json files

sql_query

Execute any SQL query on the database:

{
  "query": "SELECT TOP 10 * FROM users WHERE status = 'active'"
}

show_tables

List tables, optionally filtered by schema:

{
  "schema": "dbo"
}

describe_table

Get detailed table structure:

{
  "table_name": "users",
  "schema": "dbo"
}

generate_visualization

Create interactive charts from query results:

{
  "query": "SELECT category, SUM(amount) as total FROM sales GROUP BY category",
  "viz_type": "bar",
  "title": "Sales by Category"
}

Supported visualization types: auto, bar, scatter, pie, line, heatmap, table

generate_analysis_notebook

Create Jupyter notebook with automated analysis:

{
  "query": "SELECT * FROM sales_data WHERE date >= '2024-01-01'",
  "output_file": "sales_analysis.ipynb"
}

Security

Built-in Security Features:

  • Write operations disabled by default - All INSERT, UPDATE, DELETE operations are blocked

  • Granular permissions - Enable specific operations via environment variables

  • Encrypted connections - Uses TLS encryption by default

  • Credential protection - Database credentials stored in .env file (excluded from git)

To enable write operations:

# Enable specific operations as needed
ALLOW_INSERT_OPERATION=true
ALLOW_UPDATE_OPERATION=true
ALLOW_DELETE_OPERATION=true

Troubleshooting

Connection Issues

Problem: Cannot connect to SQL Server

#  Check server address format
MSSQL_SERVER=tcp:your-server.database.windows.net  # For Azure SQL

#  Verify firewall settings allow your IP
#  Ensure SQL Server authentication is enabled
#  Double-check credentials in .env file

Permission Errors

Problem: Access denied or operation not allowed

#  Check security settings
ALLOW_WRITE_OPERATIONS=true  # If you need write access

#  Verify database user permissions
#  Ensure user has appropriate SQL Server roles

Visualization Errors

Problem: Charts not generating correctly

  • Ensure query returns data suitable for the visualization type

  • Bar/pie charts need categorical columns

  • Scatter/line charts need numeric columns

  • Check that query returns at least one row

Common Error Messages

Error: "Login failed for user"

  • Check username and password in .env

  • Verify SQL Server authentication is enabled

Error: "Cannot open database"

  • Verify database name is correct

  • Check user has access to the specified database

Error: "Connection timeout"

  • Increase QUERY_TIMEOUT in .env

  • Check network connectivity to SQL Server

Development

Extending the Server

File Structure:

  • mssql.py - Database tools implementation

  • main.py - MCP server interface

  • .env - Configuration file

Adding New Tools:

  1. Create method in MSSQLTools class

  2. Add tool definition in list_tools()

  3. Add handler in call_tool()

Output Files

The tools generate various output files in your working directory:

  • Jupyter Notebooks: .ipynb files with analysis code

  • Visualizations: .html files with interactive charts

  • Power BI Data: .csv and .json files for import

License

MIT License - see the LICENSE file for details.

Available Tools

8 tools
describe_tableC

Get detailed information about a table's structure

ParametersJSON Schema
NameRequiredDescriptionDefault
table_nameYes
schema_nameNodbo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It states 'get detailed information' but does not specify that it is a read-only operation, what permissions are needed, or any side effects. The existence of an output schema is not leveraged in the description to clarify return structure.

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

Conciseness3/5

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

The description is very concise (one sentence) and front-loaded with the verb, but it is too terse and omits critical information about parameters and usage. Conciseness alone does not justify missing necessary content.

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

Completeness2/5

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

Despite having an output schema that could reduce the burden of describing return values, the description lacks parameter explanations and usage context. For a tool with 2 parameters and 0% schema coverage, this is insufficient.

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

Parameters1/5

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

The description does not mention any parameters. With 0% schema description coverage and two parameters (table_name, schema_name), it fails to explain their purpose, which is essential for the agent to invoke the tool correctly.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'detailed information about a table's structure', which is distinguishable from siblings like 'show_tables' (list tables) and 'show_indexes' (show indexes). However, it could be more specific about what details are included (e.g., columns, data types, constraints).

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 is provided on when to use this tool versus alternatives like 'sql_query' to retrieve schema information. There are no prerequisites, when-to-use, or when-not-to-use instructions.

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

generate_analysis_notebookC

Generate a Jupyter notebook with Python code to analyze SQL query results

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
output_fileNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.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 disclose behavioral traits, but it does not mention side effects, permissions, or whether it overwrites files. The output is vaguely described without details on the notebook type or structure.

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

Conciseness2/5

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

The description is very short, which is concise, but it sacrifices necessary detail. It is front-loaded but incomplete, resulting in under-specification.

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

Completeness1/5

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

Given the two parameters and presence of an output schema, the description is severely lacking. It does not explain the tool's workflow, return value, or constraints, leaving the agent with minimal guidance.

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

Parameters1/5

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

With 0% schema description coverage, the description must add meaning to parameters, but it fails to explain 'query' (expected format) or 'output_file' (path vs filename). The names alone are insufficient.

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 ('Generate'), the resource ('Jupyter notebook'), and the context ('to analyze SQL query results'). It is specific enough to distinguish from sibling tools like 'generate_visualization' or 'sql_query'.

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 is given on when to use this tool versus alternatives like 'generate_visualization' or 'generate_powerbi_visualization'. There is no when-not or explicit context provided.

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

generate_powerbi_visualizationC

Generate Power BI compatible data and visualization metadata

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
viz_typeNoauto

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, requires authentication, or has side effects. The output schema may clarify return values, but behavioral traits are missing.

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

Conciseness3/5

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

The description is very short (one sentence), but it is not concise in conveying useful information. It omits essential details, making it insufficient despite its brevity.

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

Completeness2/5

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

Given two parameters, no annotations, and an existing output schema, the description is incomplete. It fails to explain the query execution, prerequisite conditions, or return structure, 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.

Parameters1/5

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

Schema coverage is 0% and the description provides no parameter details. It does not explain what 'query' expects (e.g., SQL, data source) or what 'viz_type' values are allowed (enum, free text).

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

Purpose3/5

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

The description states 'Generate Power BI compatible data and visualization metadata' which indicates a specific output format, but it does not specify the action clearly (e.g., executing a query) or differentiate from sibling tool 'generate_visualization'.

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 like sql_query or generate_visualization. The description does not mention context such as database connection requirements.

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

generate_visualizationB

Generate visualizations (bar, scatter, pie, line, heatmap, table) from SQL query results

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
viz_typeNoauto
titleNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. Only states it generates from SQL query results; no disclosure of side effects, permissions, data limits, or response characteristics.

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

Conciseness4/5

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

Single sentence with front-loaded purpose. Efficient but could include more detail without being verbose.

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?

With output schema present, return values need not be detailed. However, lacks explanation of parameter behavior and use cases, leaving gaps for a 3-parameter tool.

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?

Schema coverage is 0%, but description adds minimal parameter info. Mentions viz_type implicitly via listed types, but does not explain the 'auto' default, query format, or title parameter.

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?

Description clearly states the tool generates visualizations, lists supported types (bar, scatter, pie, line, heatmap, table), and specifies input from SQL query results. This distinguishes it from siblings like generate_powerbi_visualization.

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?

Implicitly suggests use when needing visualizations from SQL queries, but no explicit guidance on when to choose this over alternatives like sql_query or generate_powerbi_visualization.

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

get_database_infoA

Get information about the database server and available databases

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

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

No annotations exist, so the description must carry the full burden. It only says 'Get information', implying a read operation, but omits behavioral traits like idempotency, authentication requirements, rate limits, or response details. With an output schema present, the structure may be documented there, but description adds no behavioral context beyond the verb.

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 with no wasted words. It efficiently communicates the tool's purpose.

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?

Given no parameters, presence of output schema, and a clear purpose, the description is largely complete. It could mention that it requires no inputs, but that is minor. Overall, it adequately covers the essentials for a simple tool.

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, so there is no need for parameter information. The description does not add parameter semantics, but the baseline for 0 parameters is 4, and there is no missing explanation.

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 uses a specific verb 'Get' and resource 'information about the database server and available databases'. It clearly distinguishes from sibling tools like 'show_tables' (lists tables) and 'describe_table' (describes a specific table) by focusing on server-level info.

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 description provides no guidance on when to use this tool versus alternatives or any exclusions. It simply states what it does, leaving the agent to infer usage context. A score of 3 is appropriate for minimal but not entirely absent guidance.

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

show_indexesC

Show indexes for a table or all tables

ParametersJSON Schema
NameRequiredDescriptionDefault
table_nameNo
schema_nameNodbo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided. The description only states 'show indexes' but does not disclose behavioral traits such as whether it is read-only, permission requirements, or what happens if table_name is omitted.

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

Conciseness3/5

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

Single sentence, front-loaded with purpose, but lacks structure. Could include parameter explanations or usage examples without being verbose.

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

Completeness2/5

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

Output schema exists (so return format is covered), but the description fails to explain parameters or provide usage context. With 0% parameter coverage and no guidance, the tool is not adequately described for an AI agent.

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?

Schema description coverage is 0%. The description hints that table_name is optional (meaning 'all tables') but does not explain schema_name or the exact meaning of parameters. Does not compensate for missing schema descriptions.

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's purpose: showing indexes. It specifies scope (for a table or all tables), distinguishing it from sibling tools like show_tables or describe_table.

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 vs alternatives. Does not mention prerequisites or context (e.g., schema requirements) or when to choose show_tables or describe_table instead.

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

show_tablesB

Show all tables in the current database

ParametersJSON Schema
NameRequiredDescriptionDefault
schema_nameNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3/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 of behavioral disclosure. It only states what the tool does (shows tables) without addressing important aspects like performance, permissions, or side effects. A more detailed description would improve transparency.

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

Conciseness4/5

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

The description is a single concise sentence with no redundancy. However, it lacks necessary details, which is a trade-off between conciseness and completeness.

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

Completeness2/5

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

Given the low complexity (1 optional parameter) and the presence of an output schema, the description is insufficient. It does not explain how the optional parameter affects results or what the returned data represents beyond listing tables.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description fails to mention the 'schema_name' parameter at all. The parameter's purpose, default behavior (null means current schema?), and usage are completely undocumented, leaving the agent to guess.

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 ('Show'), the resource ('all tables'), and the scope ('in the current database'), distinguishing it from siblings like 'describe_table' which focuses on a single table.

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 description implies usage (listing all tables) but provides no explicit guidance on when to use this tool versus alternatives like 'sql_query' or 'get_database_info'. No exclusions or prerequisites are mentioned.

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

sql_queryC

Execute a SQL query on the MS SQL Server database

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.7/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It fails to disclose potential side effects (e.g., data modification), permissions needed, or return format, despite having an output schema.

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

Conciseness4/5

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

The description is very concise: one sentence with no wasted words. However, it is under-specified, so while efficient, it sacrifices completeness.

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

Completeness2/5

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

Given the complexity of executing arbitrary SQL (potential for destructive actions) and lack of annotations or parameter documentation, the description is far from complete for safe and correct usage.

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?

Schema description coverage is 0% and the description adds no meaning to the single required parameter 'query' beyond its name and type. No format or constraints are explained.

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

Purpose4/5

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

The description clearly states it executes a SQL query on a specific database (MS SQL Server), but does not differentiate from sibling tools like describe_table or show_tables that also query the database.

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. For instance, when to use sql_query versus describe_table or show_tables is not mentioned.

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. Dates show when Glama detected each change.

  1. 8 tool updatesv0.1.0
    • First observeddescribe_table
    • First observedgenerate_analysis_notebook
    • First observedgenerate_powerbi_visualization
    • First observedgenerate_visualization
    • First observedget_database_info
    • First observedshow_indexes
    • First observedshow_tables
    • First observedsql_query
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a distinct purpose: query execution, metadata retrieval (tables, indexes, database info), and three different output generation types (notebook, PowerBI, general viz). No two tools overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (describe_table, generate_*, show_indexes, etc.) using lowercase snake_case. Slight inconsistency with 'sql_query' being noun-focused instead of verb_noun, but overall pattern is clear and predictable.

Tool Count5/5

8 tools is appropriate for a database analysis server. It covers core needs (query, metadata, visualization) without being excessive or too sparse. The count is well within the ideal 3-15 range.

Completeness4/5

The tool set covers querying, table/index metadata, and generating analysis outputs. Minor gaps like listing views or stored procedures exist, but for the stated analysis purpose it is reasonably complete.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

  • LemonadoOAuth
    io.github.lemonadolabs

    MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets

    MarketingResearch & DataDatabases
    3
  • Google Big QueryA
    com.googleapis.bigquery

    The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.

    DatabasesCloud PlatformsSearch
    63
  • Mercado PagoOAuth
    com.mercadopago.mcp

    The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.

    FinanceE-commerce & RetailApp Automation
    2
  • anotherai
    dev.anotherai

    MCP server for building and testing AI agents with multi-model experimentation and insights.

    Agent OrchestrationAutonomous AgentsTesting & QA Tools
    2

Related MCP Servers

  • MySQL-MCP

    zajTools
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables SQL query execution, database management, and business intelligence capabilities through MySQL connections.
    1,090
    MIT

  • MSSQL MCP Server

    knight0zh
    A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that enables executing SQL queries and managing connections with Microsoft SQL Server databases.
    1
    3,338
    6
    MIT

  • SQL MCP Server

    adetxt
    F
    license
    C
    quality
    D
    maintenance
    A Model Context Protocol server that provides a standardized interface for interacting with SQL databases through the MCP protocol.
    3
    20
    4
    -

  • MCPQL

    hendrickcastro
    A
    license
    B
    quality
    C
    maintenance
    A comprehensive Model Context Protocol server for SQL Server database operations that provides 10 powerful tools for database analysis, object discovery, and data manipulation.
    11
    183
    15
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SerenaHangSinclair/mcp-mssql-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server