The MSSQL MCP Server enables natural language interaction with Microsoft SQL Server databases through LLMs like Claude, facilitating comprehensive data manipulation and schema management.
Query Data: Execute SELECT queries to retrieve data from tables
Insert Data: Add single or multiple records to database tables
Update Data: Modify existing table data with mandatory WHERE clause for security
Create Tables: Define new tables with custom columns and data types
Drop Tables: Remove entire tables from the database
Create Indexes: Add indexes on columns for improved query performance
Describe Tables: Retrieve schema information including columns and data types
List Tables: View all available tables, with optional schema filtering
Secure Connections: Handle database connections securely with optional read-only mode
Enables querying, reading, and modifying Microsoft SQL Server databases (part of the .NET ecosystem) through natural language, including executing SQL operations, managing tables and indexes, and performing CRUD operations on data.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MSSQL MCP Server show me the top 10 customers by total order amount"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables LLMs like Claude to interact with Microsoft SQL Server databases through natural language.
🔍 Query your SQL Server database using natural language
📊 Read, insert, update, and delete data
🏗️ Create and manage tables and indexes
🔒 Secure connection handling with optional read-only mode
⚡ Direct TypeScript execution with tsx - no build step required
Related MCP server: ExecuteAutomation Database Server
No installation needed! Just configure Claude Desktop:
Add to %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"mssql": {
"type": "stdio",
"command": "cmd",
"args": ["/c", "npx", "-y", "github:EvilPhatBoi/McpSqlServer"],
"env": {
"SERVER_NAME": "your-server.database.windows.net",
"DATABASE_NAME": "your-database",
"SQL_USERNAME": "your-username",
"SQL_PASSWORD": "your-password",
"PORT": "1433",
"ENCRYPT": "true",
"TRUST_SERVER_CERTIFICATE": "false",
"CONNECTION_TIMEOUT": "30",
"READONLY": "false"
}
}
}
}Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"mssql": {
"type": "stdio",
"command": "npx",
"args": ["-y", "github:EvilPhatBoi/McpSqlServer"],
"env": {
"SERVER_NAME": "your-server.database.windows.net",
"DATABASE_NAME": "your-database",
"SQL_USERNAME": "your-username",
"SQL_PASSWORD": "your-password",
"PORT": "1433",
"ENCRYPT": "true",
"TRUST_SERVER_CERTIFICATE": "false",
"CONNECTION_TIMEOUT": "30",
"READONLY": "false",
"DEBUG": "false"
}
}
}
}Note for legacy SQL Servers: If you experience SSL/TLS connection issues with older SQL Server versions, try:
"ENCRYPT": "false" to disable TLS/SSL encryption
"TRUST_SERVER_CERTIFICATE": "true" to trust self-signed certificates
"CONNECTION_TIMEOUT": "60" or higher for slower connections
"DEBUG": "true" to see detailed connection logs
Clone the repository:
git clone https://github.com/EvilPhatBoi/McpSqlServer.git
cd McpSqlServerInstall dependencies:
npm installCreate .env file:
cp .env.example .env
# Edit .env with your database credentialsConfigure Claude Desktop to point to your local installation:
{
"mcpServers": {
"mssql": {
"type": "stdio",
"command": "npx",
"args": ["tsx", "C:/path/to/McpSqlServer/src/index.ts"],
"env": {
"SERVER_NAME": "your-server.database.windows.net",
"DATABASE_NAME": "your-database",
"SQL_USERNAME": "your-username",
"SQL_PASSWORD": "your-password"
}
}
}
}Variable | Description | Default |
| SQL Server hostname | Required |
| Database name | Required |
| SQL username | Required |
| SQL password | Required |
| SQL Server port |
|
| Enable TLS/SSL encryption |
|
| Trust self-signed certificates |
|
| Connection timeout in seconds |
|
| Enable read-only mode |
|
| Enable debug logging |
|
Once configured, you can interact with your database using natural language in Claude:
"Show me all customers from New York"
"Create a table called products with columns for id, name, and price"
"Update the price of product with id 5 to 29.99"
"List all tables in the database"
"Describe the structure of the orders table"
npm run start # Run the server
npm run dev # Run with watch modenpm run typecheckNever commit .env files with real credentials
Use read-only mode (READONLY=true) in production for safety
The server requires WHERE clauses for updates to prevent accidental mass updates
Consider using environment-specific credentials
Ensure your SQL Server allows remote connections
Check firewall rules for SQL Server port (default 1433, or your custom PORT setting)
Verify credentials and server name
Enable debug logging by setting DEBUG=true in your environment variables
For older SQL Server versions that don't support modern TLS, set ENCRYPT=false
If using self-signed certificates, set TRUST_SERVER_CERTIFICATE=true
For connection timeout issues, increase CONNECTION_TIMEOUT to 60 or higher
Check that your SQL Server accepts the TLS version your Node.js supports
To enable detailed logging for troubleshooting:
"env": {
"DEBUG": "true",
// ... other environment variables
}This server uses SQL authentication, not Windows authentication
Ensure SQL authentication is enabled on your server
Check that the SQL user has appropriate permissions
MIT
Creates an index on a specified column or columns in an MSSQL Database table
| Name | Required | Description | Default |
|---|---|---|---|
| schemaName | No | Name of the schema containing the table | |
| tableName | Yes | Name of the table to create index on | |
| indexName | Yes | Name for the new index | |
| columns | Yes | Array of column names to include in the index | |
| isUnique | No | Whether the index should enforce uniqueness (default: false) | |
| isClustered | No | Whether the index should be clustered (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Creates an index' implies a write operation, it doesn't specify whether this requires admin permissions, if it's reversible (e.g., via drop_table), potential performance impacts during creation, or error conditions. For a database mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. Every word earns its place without redundancy or fluff, making it easy to parse quickly while conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a database index creation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., permissions, side effects), usage context, and expected outcomes. For a mutation tool in a set of database operations, this leaves critical gaps for an agent to operate safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters well-documented in the input schema (e.g., tableName, columns, isUnique). The description adds no additional parameter semantics beyond implying column specification, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates an index') and the resource ('on a specified column or columns in an MSSQL Database table'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings (e.g., create_table, drop_table) beyond the general domain of database operations, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., table must exist), performance implications, or when to choose indexing over other operations like query optimization. With siblings like create_table and update_data, this lack of context leaves the agent without clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new table in the MSSQL Database with the specified columns.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table to create | |
| columns | Yes | Array of column definitions (e.g., [{ name: 'id', type: 'INT PRIMARY KEY' }, ...]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation operation, implying a write/mutation, but doesn't mention critical aspects like required permissions, whether it's idempotent (e.g., fails if table exists), side effects on the database, or error handling. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. There's no wasted verbiage or redundancy, making it easy to parse quickly while conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral traits (e.g., permissions, idempotency), return values, or error cases. Given the complexity of database operations and lack of structured safety hints, more context is needed to guide safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters (tableName and columns) with clear descriptions and examples. The description adds minimal value beyond stating the tool uses 'specified columns', which is already implied by the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('creates') and resource ('new table in the MSSQL Database'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_index' or 'drop_table', which would require mentioning this is for table structure creation rather than index creation or data insertion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_index' for indexes, 'insert_data' for adding data, or 'drop_table' for removal. The description lacks context about prerequisites (e.g., database permissions) or typical scenarios for table creation, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describes the schema (columns and types) of a specified MSSQL Database table.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table to describe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool's purpose but lacks behavioral details like whether it requires specific permissions, returns error messages for non-existent tables, or provides additional metadata beyond columns and types. The description doesn't contradict annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Describes the schema') and specifies the resource scope ('MSSQL Database table') and output details ('columns and types'). There is zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no annotations and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits, error handling, or output format, which would be helpful given the absence of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'tableName' well-documented in the schema. The description adds no additional parameter semantics beyond what the schema already provides, establishing the baseline score of 3 for adequate but non-enhancing coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Describes') and resource ('schema of a specified MSSQL Database table'), including what information is returned ('columns and types'). It distinguishes from siblings like list_table (which likely lists table names) and read_data (which reads table contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when schema information is needed, but provides no explicit guidance on when to use this tool versus alternatives like list_table or create_table. There are no exclusions or prerequisites mentioned, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drops a table from the MSSQL Database.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table to drop |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Drops') but doesn't disclose critical behavioral traits: it's a destructive, irreversible operation that requires specific database permissions, removes all data and structure, and likely doesn't return meaningful output. This is inadequate for a high-risk tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (destructive database operation) and lack of annotations or output schema, the description is incomplete. It fails to address risks, permissions, or output expectations, leaving significant gaps for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'tableName' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drops') and resource ('a table from the MSSQL Database'), making the purpose unambiguous. It doesn't explicitly distinguish from siblings like 'delete_data' or 'truncate_table' (if they existed), but among actual siblings, it's distinct enough as the only table-dropping operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin permissions), consequences (e.g., irreversible data loss), or when to prefer other tools like 'delete_data' for removing rows instead of dropping the entire table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inserts data into an MSSQL Database table. Supports both single record insertion and multiple record insertion using standard SQL INSERT with VALUES clause. FORMAT EXAMPLES: Single Record Insert: { "tableName": "Users", "data": { "name": "John Doe", "email": "john@example.com", "age": 30, "isActive": true, "createdDate": "2023-01-15" } } Multiple Records Insert: { "tableName": "Users", "data": [ { "name": "John Doe", "email": "john@example.com", "age": 30, "isActive": true, "createdDate": "2023-01-15" }, { "name": "Jane Smith", "email": "jane@example.com", "age": 25, "isActive": false, "createdDate": "2023-01-16" } ] } GENERATED SQL FORMAT:
Single: INSERT INTO table (col1, col2) VALUES (@param1, @param2)
Multiple: INSERT INTO table (col1, col2) VALUES (@param1, @param2), (@param3, @param4), ... IMPORTANT RULES:
For single record: Use a single object for the 'data' field
For multiple records: Use an array of objects for the 'data' field
All objects in array must have identical column names
Column names must match the actual database table columns exactly
Values should match the expected data types (string, number, boolean, date)
Use proper date format for date columns (YYYY-MM-DD or ISO format)
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table to insert data into | |
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it performs write operations (implied by 'inserts'), supports single/multiple records, generates SQL INSERT statements, and includes important rules (e.g., column name matching, data type requirements, date formats). However, it lacks details on permissions, error handling, or transaction behavior, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured with clear sections (purpose, format examples, generated SQL format, important rules) and front-loaded key information. While detailed, each sentence adds value (e.g., examples illustrate usage, rules prevent errors). Minor verbosity in repeating examples slightly reduces efficiency, but overall it's well-organized and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (write operation, variable data structures), no annotations, no output schema, and 2 parameters with partial schema coverage, the description is largely complete. It covers purpose, usage examples, SQL behavior, and critical constraints. However, it misses some context like expected return values (e.g., success confirmation or inserted IDs), error scenarios, or performance considerations, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only tableName has a description in schema), but the description compensates well by adding rich semantics: it explains the 'data' parameter's structure for single vs. multiple records with detailed examples, clarifies column name and data type requirements, and provides format rules. This goes significantly beyond the schema, though it doesn't fully document all edge cases (e.g., handling nulls).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'inserts data into an MSSQL Database table' with specific verbs ('inserts') and resources ('MSSQL Database table'), distinguishing it from sibling tools like read_data, update_data, create_table, etc. It explicitly mentions support for both single and multiple record insertion, making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through format examples and rules (e.g., 'Use a single object for the 'data' field' for single records), but does not explicitly state when to use this tool versus alternatives like update_data or create_table. No guidance on prerequisites (e.g., table must exist) or exclusions is provided, leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists tables in an MSSQL Database, or list tables in specific schemas
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | No | Schemas to filter by (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions optional schema filtering but doesn't describe output format (e.g., list of table names, metadata), pagination, error conditions, or performance implications. For a read operation with zero annotation coverage, this is insufficient to inform the agent adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that efficiently conveys the core functionality and optional filtering. There is no wasted language, and it's front-loaded with the primary action, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a database tool. It doesn't explain what the output looks like (e.g., structured data vs. raw list), potential errors (e.g., invalid schemas), or how it integrates with siblings like 'describe_table'. For a tool in a database context with multiple related operations, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the single optional parameter ('Schemas to filter by'). The description adds marginal value by restating that schemas are optional for filtering, but doesn't provide additional context like schema naming conventions or examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Lists') and resource ('tables in an MSSQL Database'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'describe_table' or 'read_data' which also involve table operations, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., database connection), compare to siblings like 'describe_table' for detailed table info, or specify scenarios where listing tables is appropriate versus other operations. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a SELECT query on an MSSQL Database table. The query must start with SELECT and cannot contain any destructive SQL operations for security reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL SELECT query to execute (must start with SELECT and cannot contain destructive operations). Example: SELECT * FROM movies WHERE genre = 'comedy' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying security constraints (must start with SELECT, no destructive operations) and the database type (MSSQL), which aren't in the schema. However, it lacks details on error handling, performance limits, or return format, leaving gaps for a tool that executes arbitrary SQL queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that clearly state the purpose and key constraints. There's no unnecessary repetition or fluff, and it efficiently communicates essential information without wasting words, though it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing arbitrary SQL queries, no annotations, and no output schema, the description is moderately complete. It covers the core purpose and security constraints but lacks details on behavioral aspects like error messages, result formatting, or rate limits, which are important for an AI agent to use this tool effectively in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'query' parameter well-documented in the schema itself. The description adds minimal semantic value beyond the schema by repeating the constraints (must start with SELECT, no destructive operations) but doesn't provide additional context like query formatting tips or examples not in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Executes a SELECT query on an MSSQL Database table.' It specifies the verb ('executes'), resource ('MSSQL Database table'), and operation type ('SELECT query'). However, it doesn't explicitly differentiate from sibling tools like 'list_table' or 'describe_table', which might also read data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating that the query 'must start with SELECT and cannot contain any destructive SQL operations for security reasons,' which implies this tool is for safe read-only queries. However, it doesn't explicitly mention when to use this tool versus alternatives like 'list_table' or 'describe_table' from the sibling list, leaving usage guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates data in an MSSQL Database table using a WHERE clause. The WHERE clause must be provided for security.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Name of the table to update | |
| updates | Yes | Key-value pairs of columns to update. Example: { 'status': 'active', 'last_updated': '2025-01-01' } | |
| whereClause | Yes | WHERE clause to identify which records to update. Example: "genre = 'comedy' AND created_date <= '2025-07-05'" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the WHERE clause requirement for security, which is useful context, but fails to cover critical aspects: it doesn't specify whether this is a destructive operation, what permissions are needed, how errors are handled, or what the response looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences, front-loading the core purpose and following with a critical constraint. Every word earns its place, with no redundant or vague language, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a database mutation operation with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits like destructiveness, error handling, or return values, and while the schema covers parameters well, the overall context for safe and effective use is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by emphasizing the WHERE clause's security importance, but it doesn't provide additional syntax, format details, or examples that aren't already in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Updates data') and resource ('in an MSSQL Database table'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'insert_data' or 'read_data' beyond the basic verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance by specifying that 'The WHERE clause must be provided for security,' which implies a usage constraint. However, it doesn't offer explicit guidance on when to use this tool versus alternatives like 'insert_data' or 'read_data,' nor does it mention prerequisites or exclusions beyond the WHERE clause requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
create_indexcreate_tabledescribe_tabledrop_tableinsert_datalist_tableread_dataupdate_dataEach tool has a clearly distinct purpose with no ambiguity. create_index, create_table, describe_table, drop_table, insert_data, list_table, read_data, and update_data each target specific database operations with no overlap in functionality. The descriptions clearly differentiate between schema operations, data manipulation, and querying.
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming convention is perfectly uniform: create_index, create_table, describe_table, drop_table, insert_data, list_table, read_data, and update_data all maintain the same structure and style.
With 8 tools, this server is well-scoped for MSSQL database operations. Each tool earns its place by covering essential database tasks: schema management (create/drop/describe/list tables, create index) and data operations (insert/read/update). The count is appropriate for the domain without being overwhelming.
The tool surface covers most essential MSSQL operations well, including table lifecycle management and core CRUD operations. However, there are minor gaps: no delete_data tool (only update_data with WHERE clause), no transaction management tools, and no stored procedure or view operations. Agents can work around these gaps using existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
GibsonAI MCP server: manage your databases with natural language
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.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/EvilPhatBoi/McpSqlServer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
