Which integrations are available for this server?

Uses environment variables for configuration of database connections and server settings. Uses Jest for comprehensive testing of schema validation and core database functionality. Runs on Node.js platform to provide SQL Server connectivity and database operations via MCP protocol. Recommended package manager for installing and managing dependencies of the MCP server. Provides type safety and TypeScript implementation for database operations through the MCP server. Utilizes Zod for runtime type validation of database queries and parameters.

How do I use SQL Server MCP Service?

1. Click on "Install 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., "@SQL Server MCP Service show me the top 10 customers by order value" 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.

SQL Server MCP Service

by vini-cius

Overview Schema Related Servers Score Discussions

TypeScript

Remote

SQL Server MCP Service

License: MIT Node.js Version TypeScript

A secure and robust Model Context Protocol (MCP) service for executing SQL Server queries via MCP protocol. This service provides a safe way to interact with SQL Server databases while preventing destructive operations and SQL injection attacks.

🚀 Features

🔒 Secure Query Execution: Built-in protection against SQL injection and destructive operations
📊 Schema Discovery: Get table, function, and procedure schemas and database information
🛠️ Multiple Tools: 9 specialized tools for different database operations
⚡ High Performance: Connection pooling for efficient database operations
🔧 TypeScript Support: Full TypeScript implementation with type safety
🧪 Comprehensive Testing: Jest-based test suite for reliability

Related MCP server: MSSQL MCP Server

🛠️ Available Tools

1. `execute_query`

Executes safe SQL queries with parameter support.

Parameters:

query (string, required): The SQL query to execute
parameters (object, optional): Query parameters for prepared statements

Example:

{
  "query": "SELECT * FROM Users WHERE Status = @status",
  "parameters": {
    "status": "active"
  }
}

2. `get_table_schema`

Retrieves detailed column information for a specific table.

Parameters:

tableName (string, required): Name of the table
schemaName (string, optional): Schema name (default: "dbo")

Example:

{
  "tableName": "Users",
  "schemaName": "dbo"
}

3. `list_tables`

Lists all tables in the database with optional schema filtering.

Parameters:

schemaName (string, optional): Filter tables by specific schema

Example:

{
  "schemaName": "dbo"
}

4. `get_database_info`

Retrieves general database information (name, version, edition, etc.).

Parameters: None

5. `list_procedures`

Lists all stored procedures in the database, optionally filtered by schema.

Parameters:

schemaName (string, optional): Filter procedures by schema

Example:

{
  "schemaName": "dbo"
}

6. `list_functions`

Lists all functions (scalar and table-valued) in the database, optionally filtered by schema and function type.

Parameters:

schemaName (string, optional): Filter functions by schema
functionType (string, optional): 'SCALAR' or 'TABLE'

Example:

{
  "schemaName": "dbo",
  "functionType": "SCALAR"
}

7. `get_procedure_schema`

Gets the schema and parameters of a specific stored procedure.

Parameters:

procedureName (string, required): Name of the procedure
schemaName (string, optional): Schema name (default: "dbo")

Example:

{
  "procedureName": "MyProcedure",
  "schemaName": "dbo"
}

8. `get_function_schema`

Gets the schema and parameters of a specific function.

Parameters:

functionName (string, required): Name of the function
schemaName (string, optional): Schema name (default: "dbo")

Example:

{
  "functionName": "MyFunction",
  "schemaName": "dbo"
}

9. `execute_procedure`

Executes a stored procedure with parameters.

Parameters:

procedureName (string, required): Name of the procedure
parameters (object, optional): Procedure parameters
schemaName (string, optional): Schema name (default: "dbo")

Example:

{
  "procedureName": "MyProcedure",
  "parameters": {
    "param1": 123,
    "param2": "abc"
  },
  "schemaName": "dbo"
}

📦 Installation

Prerequisites

Node.js >= 20.0.0
SQL Server instance
pnpm (recommended)

Install Dependencies

pnpm install

⚙️ Configuration

Copy Environment Template

cp .env.example .env

Configure Environment Variables

Variable	Description	Default
`HTTP_PORT`	HTTP server port	`3333`
`NODE_ENV`	Node environment (`development`/`production`)	`development`
`ORIGIN`	Allowed CORS origins (comma-separated)	-
`SQL_SERVER`	SQL Server hostname/IP	`localhost`
`SQL_DATABASE`	Database name	`master`
`SQL_USER`	Database username	-
`SQL_PASSWORD`	Database password	-
`SQL_PORT`	SQL Server port	`1433`
`SQL_ENCRYPT`	Enable encryption	`true`
`SQL_TRUST_CERT`	Trust server certificate	`false`

Example .env:

HTTP_PORT=3333
NODE_ENV=development
ORIGIN=http://localhost:3000,http://example.com
SQL_SERVER=localhost
SQL_DATABASE=master
SQL_USER=sa
SQL_PASSWORD=YourSecurePassword123!
SQL_PORT=1433
SQL_ENCRYPT=true
SQL_TRUST_CERT=false

🚀 Usage

Start HTTP Server (Recommended)

pnpm run dev:http
# or
pnpm run start:http

Build for Production

pnpm run build

Running Tests

pnpm run test

🖥️ Desktop App Integration

To integrate this server with a desktop app, add the following to your app's server configuration:

Using Node.js directly:

{
  "mcpServers": {
    "sqlserver": {
      "command": "node",
      "args": [
        "{ABSOLUTE PATH TO FILE HERE}/dist/cli.js"
      ]
    }
  }
}

Using npx:

{
  "mcpServers": {
    "sqlserver": {
      "command": "npx",
      "args": [
        "mcp-mssql-server"
      ]
    }
  }
}

Note: Replace {ABSOLUTE PATH TO FILE HERE} with the actual absolute path to your project's dist/cli.js file.

🤖 OpenAI Integration

To use this MCP server with OpenAI's API, you can integrate it using the MCP protocol. Here's an example:

import OpenAI from "openai";
const client = new OpenAI();

const resp = await client.responses.create({
  model: "gpt-5",
  tools: [
    {
      type: "mcp",
      server_label: "mssql",
      server_description: "A SQL Server MCP server for executing safe database queries and schema discovery.",
      server_url: "http://localhost:3333/mcp",
      require_approval: "never",
    },
  ],
  input: "Show me all tables in the database",
});

console.log(resp.output_text);

Note: Make sure your HTTP server is running on the specified port before making requests to OpenAI.

🔒 Security Features

Query Validation

The service automatically blocks potentially destructive operations:

❌ DROP TABLE
❌ DELETE FROM
❌ TRUNCATE TABLE
❌ INSERT INTO
❌ UPDATE
❌ CREATE TABLE
❌ ALTER TABLE
❌ Stored procedures (sp_, xp_)
❌ SQL injection patterns
❌ Comments (--, /* */)

Allowed Operations

✅ SELECT queries
✅ WITH clauses (CTEs)
✅ SHOW commands
✅ DESCRIBE commands
✅ EXPLAIN commands
✅ Safe EXEC/EXECUTE for procedures/functions

Parameter Sanitization

All query and procedure parameters are automatically sanitized to prevent injection attacks.

🧪 Testing

The project includes comprehensive tests for schema validation and core functionality:

# Run all tests
pnpm run test

# Run tests in watch mode
pnpm run test -- --watch

# Run tests with coverage
pnpm run test -- --coverage

📝 License

This project is licensed under the MIT License - see the LICENSE file for details.

👨‍💻 Author

Vinicius de Souza Santos

Email: viniciuskt0@gmail.com
GitHub: @vini-cius

🙏 Acknowledgments

Model Context Protocol for the MCP specification
mssql for SQL Server connectivity
Zod for runtime type validation

⭐ If this project helps you, please give it a star!

Available Tools

9 tools

execute_procedureC

Executes a stored procedure with parameters

ParametersJSON Schema

Name	Required	Description	Default
`procedureName`	Yes	Name of the stored procedure to execute
`parameters`	No	Procedure parameters
`schemaName`	No	Schema name (default: dbo)	dbo

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure, but it only states that the tool executes a procedure with parameters. It does not mention whether the procedure returns results, handles errors, or has side effects, leaving significant ambiguity.

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 core purpose. Every word earns its place, and there is no extraneous information.

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?

For a tool that executes stored procedures with no output schema, the description omits critical context such as return values, error handling, and behavior when procedures return multiple result sets. The agent is left to guess the interaction model.

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

Parameters3/5

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

The input schema already describes all three parameters with 100% coverage, so the description adds no additional meaning. A 3 is appropriate as the schema does the heavy lifting, but the description fails to clarify how to structure the 'parameters' object or any special constraints.

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 action ('Executes') and the resource ('stored procedure'), and it distinguishes this tool from sibling tools like 'get_procedure_schema' or 'execute_query'. However, it lacks specificity about the scope or side effects.

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 such as 'execute_query' or 'get_procedure_schema'. The agent receives no context about prerequisites or preferred use cases.

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

execute_queryC

Executes a SQL query in SQL Server

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query to execute
`parameters`	No	Query parameters (optional)

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits but only states it 'executes a SQL query'. It fails to mention important aspects such as potential destructiveness, required permissions, or side effects of arbitrary SQL execution.

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) with no fluff, but it is too minimal for a tool that can execute arbitrary SQL. It does not earn its place by providing sufficient information.

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 SQL queries (potential for data modification, error handling, return format), the description is incomplete. It does not explain what the tool returns or any limitations, especially with no output schema.

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

Parameters3/5

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 no additional meaning beyond what the schema provides, so it meets the baseline without adding value.

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 action ('executes') and the resource ('SQL query in SQL Server'), making the purpose understandable. However, it does not differentiate from the sibling tool 'execute_procedure', which is a similar operation.

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 'execute_procedure'. The description lacks context about use cases, prerequisites, or conditions.

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

get_database_infoC

Gets general information from the database

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and the description only says 'gets general information' without disclosing behavioral traits like read-only nature, permissions needed, or side effects. The description fails to compensate for the lack of annotations.

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 short sentence, concise and to the point. However, it could be slightly more informative without adding length, but it avoids unnecessary verbosity.

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 no parameters, no output schema, and no annotations, the description is inadequate. It does not specify what the tool returns, prerequisites, or how it differs from similar tools like get_table_schema, leaving a significant gap in completeness.

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

Parameters3/5

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

The input schema has no parameters, so schema coverage is 100% trivially. The description adds no value beyond the name; it does not explain what 'general information' means or expected output. For a parameterless tool, more context would elevate the score.

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 tool gets general database information, distinguishing it from siblings like execute_query or list_tables. However, 'general information' is vague and lacks specificity.

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 siblings. The description does not provide context or exclusion criteria, leaving the agent without direction for appropriate invocation.

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

get_function_schemaC

Gets the schema and parameters of a specific function

ParametersJSON Schema

Name	Required	Description	Default
`functionName`	Yes	Name of the function
`schemaName`	No	Schema name (default: dbo)	dbo

TDQS

C2.9/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 fully disclose behavior. It implies a read-only operation but does not mention permissions, side effects, or response format. Minimal transparency for a schema retrieval tool.

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 of 9 words is very concise and front-loaded, but the brevity sacrifices necessary detail for 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 no output schema, the description does not explain the return value (e.g., column names, types). Lacks behavioral or contextual information that would help an agent judge completeness.

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

Parameters3/5

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds no extra meaning beyond what the input schema provides, so baseline score applies.

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 tool retrieves the schema and parameters of a specific function, distinguishing it from sibling tools like get_procedure_schema or get_table_schema. However, it could be more precise about what 'schema' includes (e.g., DDL metadata).

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 like list_functions for listing function names or get_procedure_schema for procedures. The description does not mention prerequisites or when not to use it.

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

get_procedure_schemaA

Gets the schema and parameters of a specific stored procedure

ParametersJSON Schema

Name	Required	Description	Default
`procedureName`	Yes	Name of the stored procedure
`schemaName`	No	Schema name (default: dbo)	dbo

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It indicates a read operation with no side effects, but does not detail what 'schema and parameters' entails (e.g., types, defaults, permissions). The description is adequate but lacks depth.

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, well-structured sentence that directly conveys the tool's purpose with no superfluous words. It is front-loaded and efficient.

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?

The tool is simple with two parameters and no output schema. The description sufficiently explains the tool's function for a read-only schema retrieval, though it could briefly mention what the returned schema includes.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already describes both parameters. The description does not add any additional meaning beyond what is in the schema, meeting the baseline.

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 gets the schema and parameters of a stored procedure, using a specific verb and resource. It distinguishes from sibling tools like execute_procedure (execution) and get_table_schema (table schema).

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 use for stored procedures but does not provide explicit guidance on when to use this tool versus alternatives like get_function_schema. No exclusions or when-not conditions are mentioned.

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

get_table_schemaC

Gets the schema of a specific table

ParametersJSON Schema

Name	Required	Description	Default
`tableName`	Yes	Name of the table
`schemaName`	No	Schema name (default: dbo)	dbo

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavior. It states a read-like operation but does not clarify side effects, permissions, or return format (e.g., column names, data types). The lack of output schema amplifies this gap.

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, direct sentence with no superfluous words. It is appropriately sized for a simple tool, though it could benefit from additional detail.

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?

For a schema-retrieval tool without an output schema, the description should indicate the type of information returned (e.g., columns, types). The current description is too vague to fully inform an agent about what 'schema' entails.

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

Parameters3/5

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

Schema coverage is 100%, and the parameter descriptions in the schema are self-explanatory ('Name of the table', 'Schema name'). The description does not add additional semantic meaning beyond what the schema provides, meeting the baseline of 3.

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 'Gets' and the resource 'schema of a specific table', distinguishing it from sibling tools like get_procedure_schema and get_function_schema. It is specific enough for an agent to identify the tool's target.

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 list_tables or other get_*_schema tools. The description does not mention context, prerequisites, or exclusions.

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

list_functionsA

Lists all functions (scalar and table-valued) in the database

ParametersJSON Schema

Name	Required	Description	Default
`schemaName`	No	Schema name to filter functions
`functionType`	No	Type of function to filter

TDQS

A3.5/5.0

Behavior3/5

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

No annotations exist, so description carries burden. It implies a read operation but does not explicitly confirm safety, side effects, or permissions. Adequate for a simple listing but lacks depth.

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 clear sentence, front-loaded with purpose, and contains no redundant words.

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 no output schema, the description does not explain return format or what fields are included (e.g., name, schema). It covers the purpose but lacks completeness for a tool with no output schema.

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

Parameters3/5

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

Schema description coverage is 100%, with parameter descriptions already present. The tool description adds no further meaning beyond the schema, so baseline score of 3 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 uses a specific verb 'lists' and resource 'functions', includes the scope 'in the database', and clarifies both scalar and table-valued types, distinguishing it from sibling tools like list_procedures 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.

Usage Guidelines2/5

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

No usage guidelines provided; no indication of when to use this versus other listing tools, or any prerequisites or filters behavior.

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

list_proceduresC

Lists all stored procedures in the database

ParametersJSON Schema

Name	Required	Description	Default
`schemaName`	No	Schema name to filter procedures

TDQS

C2.9/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 states 'lists all stored procedures' but does not disclose whether it returns only accessible procedures, or if filtering by schemaName affects the result. No information on permissions or performance implications.

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. It could be improved by front-loading key details, but it is efficient and clear.

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 the simple interface (1 optional param, no output schema), the description is moderately complete. However, it lacks details on what the output contains (e.g., names, schemas, metadata) and does not mention the optional filter functionality.

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

Parameters3/5

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

Schema description coverage is 100% for the only parameter (schemaName). The description adds no extra meaning beyond the schema, so baseline 3 applies.

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 'Lists all stored procedures in the database' clearly states the action (list) and resource (stored procedures). It distinguishes from siblings like list_functions and list_tables, but could be more specific about the scope (e.g., all procedures in the current database context).

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 siblings like get_procedure_schema or execute_procedure. No alternatives or exclusions are mentioned, leaving the agent to infer appropriate usage.

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

list_tablesB

Lists all the tables in the database

ParametersJSON Schema

Name	Required	Description	Default
`schemaName`	No	Schema name to filter tables (default: dbo)	dbo

TDQS

B3.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 the burden of disclosure. It fails to mention any behavioral traits such as whether the tool returns only table names or includes metadata, pagination behavior, or access restrictions. The description is too minimal to inform the agent of important behaviors.

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 short sentence, which is concise and front-loaded. However, it could be slightly improved by mentioning the optional schema filter for clarity.

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 the low complexity (1 optional parameter, no output schema), the description is mostly complete but lacks behavioral context such as authentication assumptions or result format. Without annotations, the agent may miss important usage constraints.

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

Parameters3/5

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

Schema description coverage is 100% (the parameter schemaName is well-described). The description adds no further meaning beyond the schema, but given full coverage, a baseline of 3 is appropriate. The description implies listing all tables without mentioning the filtering capability.

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: 'Lists all the tables in the database', with a specific verb and resource. It effectively distinguishes from sibling tools like get_table_schema (which returns schema of a specific table) and list_functions (which lists functions).

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, such as when to filter by schemaName or when to use get_table_schema instead. No exclusions or context for selection are given.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a distinct purpose: execute vs query, schema retrieval for different objects, listing functions/procedures/tables, and general database info. No overlap.

Naming Consistency5/5

All tools follow the verb_noun pattern (execute_, get_, list_) with clear and consistent naming.

Tool Count5/5

9 tools is well-scoped for a SQL Server service, covering core operations without unnecessary bloat.

Completeness4/5

Covers querying, execution, schema retrieval, and listing. Minor gaps like transaction control or listing schemas, but sufficient for typical use.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Google Big Query A
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.
Databases Cloud Platforms Search
63
Algenta MCP Server C
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
1402
DB Query Guard MCP
com.clauxel.dbqueryguard
Paid remote MCP for governed database query review, SQL simulation, approvals, and audits.
Databases Security
2
Studex MCP Server
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1

Related MCP Servers

MSSQL MCP Server
Databases Developer Tools Code Execution
c0h1b4
A
license
B
quality
D
maintenance
Enables execution of SQL queries and management of Microsoft SQL Server database connections through the Model Context Protocol.
Updated a year ago (2025-06-05 18:32 UTC)
33
3,338
15
MIT
MSSQL MCP Server
Databases Developer Tools
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.
Updated a year ago (2025-03-10 01:46 UTC)
1
3,338
6
MIT
MSSQL MCP Server
Databases Developer Tools
NakiriYuuzu
A
license
A
quality
C
maintenance
Enables interaction with Microsoft SQL Server databases through a Model Context Protocol interface, supporting database connections, switching between databases, and executing secure SELECT queries.
Updated 9 months ago (2025-11-24 05:29 UTC)
8
22
MIT
sql-mcp
Databases Developer Tools
NakiriYuuzu
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server for interacting with MSSQL and PostgreSQL databases, offering tools for schema exploration and SQL execution. It features configurable query modes for safety and supports advanced authentication methods like Windows Auth and SSL.
Updated 4 months ago (2026-04-23 00:25 UTC)
17
MIT

Appeared in Searches

Giving Claude full access to SQL Server for free

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/vini-cius/mcp-sqlserver'

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

SQL Server MCP Service

🚀 Features

🛠️ Available Tools

1. execute_query

2. get_table_schema

3. list_tables

4. get_database_info

5. list_procedures

6. list_functions

7. get_procedure_schema

8. get_function_schema

9. execute_procedure

📦 Installation

Prerequisites

Install Dependencies

⚙️ Configuration

🚀 Usage

Start HTTP Server (Recommended)

Build for Production

Running Tests

🖥️ Desktop App Integration

Using Node.js directly:

Using npx:

🤖 OpenAI Integration

🔒 Security Features

Query Validation

Allowed Operations

Parameter Sanitization

🧪 Testing

📝 License

👨‍💻 Author

🙏 Acknowledgments

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `execute_query`

2. `get_table_schema`

3. `list_tables`

4. `get_database_info`

5. `list_procedures`

6. `list_functions`

7. `get_procedure_schema`

8. `get_function_schema`

9. `execute_procedure`