This server is a Model Context Protocol (MCP) server that lets AI assistants inspect and manipulate a Microsoft SQL Server database through schema exploration, CRUD operations, and custom SQL execution.
Schema inspection: List user schemas, list tables/views, get detailed table schemas (columns, keys, identities), and retrieve full database schema.
Read data: Query records with filters, sorting, and pagination, or run custom read-only T-SQL SELECT queries with parameters.
Write data: Insert single or bulk records, update matching rows via a WHERE clause, and delete rows safely with a required WHERE clause.
Execute arbitrary SQL: Run DDL/DML statements like CREATE, ALTER, DROP, INSERT, UPDATE, DELETE.
MCP resources: Access database schema and table list as resources via sqlserver://schema and sqlserver://tables.
Flexible SQL Server connectivity: Supports standard SQL Server connections via pyodbc/pymssql and native SQL Server Express LocalDB support, including attaching .mdf files.
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., "@SQL Server MCP Server list the first 10 records from the Customers table"
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 in Python for integration with Microsoft SQL Server databases.
The server provides complete schema inspection tools and CRUD (Create, Read, Update, Delete) operations, as well as MCP resources for quick data and schema queries.
list_schemas(): Lists all user schemas present in the database.
list_tables(schema_name=None): Lists database tables and views with the option to filter by schema.
get_table_schema(table_name, schema_name="dbo"): Returns structural details of the table (columns, data types, primary keys, foreign keys, and identities).
get_database_schema(schema_name=None, table_name=None): Returns the complete database schema or a filtered one.
read_records(table_name, schema_name="dbo", columns=None, where_clause=None, params=None, order_by=None, limit=100, offset=0): Queries records from a table with custom columns, parameterized WHERE filters, ordering, and pagination.
read_query(sql_query, params=None): Executes a custom SELECT query in T-SQL with support for positional parameters (?).
insert_record(table_name, data, schema_name="dbo"): Inserts a single record (key/value dictionary) into a table.
bulk_insert_records(table_name, records, schema_name="dbo"): Inserts multiple records in batch within a transaction.
update_records(table_name, data, where_clause, where_params=None, schema_name="dbo"): Updates records matching a parameterized WHERE clause.
delete_records(table_name, where_clause, params=None, schema_name="dbo"): Safely removes records matching a WHERE clause.
execute_sql(sql_statement, params=None): Executes arbitrary DDL/DML commands (CREATE, ALTER, DROP, INSERT, UPDATE, DELETE).
Related MCP server: SQL Server MCP
sqlserver://schema: Returns the complete database schema in JSON format.
sqlserver://tables: Returns the list of available tables and views.
Python >= 3.10
SQL Server Driver (Supports pyodbc with SQL Server ODBC Driver and pymssql for pure Python connections).
.env)Create a .env file in the project root or define the environment variables:
SQLSERVER_HOST=localhost
SQLSERVER_PORT=1433
SQLSERVER_DATABASE=MeuBanco
SQLSERVER_USER=sa
SQLSERVER_PASSWORD=SuaSenha123!
SQLSERVER_DRIVER_TYPE=auto
SQLSERVER_TRUST_SERVER_CERTIFICATE=truepython -m venv .venv
# Windows
.\.venv\Scripts\activate
# Linux/macOS
source .venv/bin/activate
pip install -e .mcp.json / Client Configuration{
"mcpServers": {
"sql-server": {
"command": "python",
"args": [
"-m",
"sql_server_mcp.server"
],
"env": {
"SQLSERVER_HOST": "localhost",
"SQLSERVER_PORT": "1433",
"SQLSERVER_DATABASE": "MeuBanco",
"SQLSERVER_USER": "sa",
"SQLSERVER_PASSWORD": "SuaSenha123!",
"SQLSERVER_TRUST_SERVER_CERTIFICATE": "true"
}
}
}
}You can use the Makefile to facilitate building and running via Docker:
# Compilar a imagem Docker
make build
# Executar o servidor MCP em container utilizando as variáveis do .env
make run
# Rodar os testes unitários dentro do container Docker
make docker-test
# Exibir ajuda dos comandos Makefile
make helpTo run the application's unit tests:
pytestInsert multiple records into a database table in a single transaction (Batch Create).
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | List of record dictionaries. | |
| table_name | Yes | Target table name. | |
| schema_name | No | Target schema name (default: 'dbo'). | dbo |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the important transactional behavior ('single transaction'), which implies atomicity, but it does not mention error handling, rollback behavior, return values, or permission requirements. This is meaningful but still incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the core purpose and the key transactional nuance. Every word earns its place, with no filler or redundancy.
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?
The tool has an output schema, so return-value documentation is not required from the description. However, the description omates usage guidance and error semantics, and given the presence of sibling tools like insert_record and execute_sql, more context on when to choose this tool would improve completeness. The transactional note helps but leaves gaps.
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 parameters are already fully documented in the schema. The description adds no additional parameter-level meaning beyond the 'multiple records' concept, which is already captured by the records parameter. Baseline 3 is appropriate.
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 uses a specific verb ('Insert') and resource ('multiple records into a database table'), and explicitly distinguishes this from single-record insertion via 'Batch Create' and 'single transaction'. It clearly positions the tool relative to siblings like insert_record.
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 phrase 'multiple records' and 'Batch Create' clearly imply this tool is for bulk insertion rather than single-record inserts, and the sibling insert_record reinforces that contrast. However, it does not explicitly name alternatives or state when not to use it, such as for small single-record operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete records from a table matching a WHERE clause (Delete).
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Positional parameter values for the WHERE clause placeholders. | |
| table_name | Yes | Target table name. | |
| schema_name | No | Target schema name (default: 'dbo'). | dbo |
| where_clause | Yes | SQL WHERE clause expression (required to avoid accidental full table deletion). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It says 'Delete records' but does not mention that this is a permanent, destructive action, whether it returns deleted rows, whether it is transactional, or any safety implications beyond the schema's note about accidental full table deletion. Minimal behavior disclosure for a destructive 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 sentence, extremely concise with no redundant wording. It is front-loaded with the core action. However, it is so minimal that it might be considered under-specified, but for conciseness it is highly efficient.
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 destructive tool with no annotations, the description is incomplete. It does not explain return values, side effects, or cautionary notes. The output schema exists but isn't described, and no context about irreversible consequences is provided. Given the tool's nature and sibling operations, more detail 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?
The input schema covers all four parameters with descriptive text (e.g., 'Target table name', 'SQL WHERE clause expression'), and the description does not add further semantic meaning. Since schema coverage is 100%, the baseline of 3 applies; the description adds no extra clarity beyond the schema.
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 (delete) and the target (records from a table using a WHERE clause). It distinguishes from read and update tools by the verb, though it doesn't explicitly contrast with sibling tools. The purpose is specific and unambiguous.
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 update_records or read_records. There is no mention of prerequisites, caution, or when deletion is appropriate. The description simply states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary SQL statements such as DDL (CREATE, ALTER, DROP) or DML (INSERT, UPDATE, DELETE).
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Positional parameter values for query placeholders (?). | |
| sql_statement | Yes | T-SQL statement to execute. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only lists DDL/DML categories without disclosing safety-relevant behavior such as irreversibility, lack of validation, or the ability to affect schema/data arbitrarily. Since annotations are absent, the description carries the full burden and under-delivers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the operation, the resource, and representative sub-actions. Every word contributes value, with no filler or redundancy.
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 high-flexibility arbitrary SQL tool, the description is minimally adequate but omits guidance on side effects, alternatives, or execution behavior beyond the raw examples. The presence of an output schema reduces the need to document return values, but the overall context is thin.
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 both parameters are already well documented by the input schema. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.
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 uses a specific verb ('Execute') with a clear resource ('arbitrary SQL statements') and enumerates DDL/DML examples. This differentiates it from the narrow sibling tools like insert_record or read_records.
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 phrase 'arbitrary SQL statements' and the DDL/DML examples imply a general-purpose fallback, but the description does not explicitly state when to prefer dedicated sibling tools (e.g., insert_record, update_records) or when not to use execute_sql. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete database schema or filter by schema and table name.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | No | Optional single table filter. | |
| schema_name | No | Optional schema filter. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It only says 'Get' which implies read-only, but does not mention potential large result sizes, pagination, or any limitations. No contradiction, but no meaningful behavioral disclosure beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple tool, though it does not elaborate on edge cases, which keeps it concise.
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 simplicity and the presence of an output schema, the description covers the core functionality adequately. However, it fails to mention relationships with siblings (e.g., when to use get_table_schema instead), leaving a slight gap in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are well documented in the schema. The description adds the context that filters are optional and that without them the complete schema is returned, which slightly enhances understanding but does not go beyond what the schema already implies.
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 uses a specific verb 'Get' and resource 'complete database schema', clearly distinguishing it from siblings like get_table_schema (which handles a single table) and list_schemas (which lists schemas). The optional filter condition adds further clarity on scope.
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 only states what the tool does without offering any guidance on when to use this versus alternatives. No exclusions or alternatives are mentioned, leaving the agent to infer context from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed schema definition for a specific table or view including columns, data types, primary keys, and foreign keys.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Name of the table or view. | |
| schema_name | No | Schema name (default: 'dbo'). | dbo |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states what the tool returns (columns, data types, keys) which is useful, but it doesn't disclose any potential limitations, error conditions, or permission requirements. However, since it's a read-only 'get' operation looks safe, and it does mention the scope (specific table/view), it provides some transparency. It doesn't contradict anything, but could be more explicit about behavior beyond just the result content.
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?
One clear sentence, immediate verb and resource, no fluff.
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 simplicity (2 params, read-only) and presence of output schema, the description covers the essential purpose. It could mention when to use this versus get_database_schema, but for a focused tool, it's adequate. It doesn't describe error conditions or authorization, but those are less critical for a read-only get. I'd give a 4 because it's not missing significant context.
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% (both parameters have descriptions in the schema). The tool description doesn't add any new information about parameters beyond what's in the schema. So baseline 3 is appropriate.
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 function: retrieving a detailed schema definition for a specific table or view, listing the key components (columns, data types, primary keys, foreign keys). This is specific and distinguishes it from siblings like list_tables (lists tables) and get_database_schema (likely broader).
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 when to use it (when you need schema details of a table), but it does not explicitly contrast with alternatives like get_database_schema or list_tables, nor does it mention any cautionary notes such as when not to use it. It's clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert a single record into a database table (Create).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Dictionary mapping column names to values (e.g., {"first_name": "John", "age": 30}). | |
| table_name | Yes | Target table name. | |
| schema_name | No | Target schema name (default: 'dbo'). | dbo |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It lacks any mention of side effects, validation, error handling, or data integrity checks, leaving the tool's behavior entirely opaque.
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, succinct sentence that directly conveys the core function without unnecessary verbosity or structural complexity.
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?
The description is too minimal to be complete. It does not clarify the tool's role within the broader set of database operations, nor does it address potential edge cases or expected behavior, despite the availability of sibling tools that could benefit from explicit differentiation.
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 already describes all parameters (coverage 100%), so the baseline is 3. The description adds no additional meaning about parameter relationships, constraints, or usage nuances beyond the schema.
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 ('Insert a single record') and the resource ('database table'), with the '(Create)' clarifying the CRUD operation. It effectively distinguishes from 'bulk_insert_records' by specifying 'single record'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like 'bulk_insert_records' or 'execute_sql'. It only describes the action without contrasting use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all user schemas in the SQL Server database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It correctly implies a read-only operation ('List all'), but does not disclose any specific behaviors such as whether it returns a complete list, whether any filtering applies, or any potential side effects. The description is minimal and does not add much beyond what the name already conveys.
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 concise sentence with no wasted words. It is front-loaded and perfectly sized for a simple list operation.
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 simplicity (no parameters, no annotations, but an output schema exists), the description is complete enough. It conveys exactly what the tool does. The output schema presumably documents the return format, so no further elaboration 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?
The tool has zero parameters, so there are no semantics to clarify. The description explicitly says 'all user schemas,' which effectively covers the scope. With no parameters, a baseline of 4 is appropriate since the description adds context about the scope ('all user schemas').
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 function: 'List all user schemas in the SQL Server database.' It uses a specific verb ('List') and resource ('user schemas'), and is clearly distinguished from siblings like list_tables and get_table_schema by focusing on schemas specifically.
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 you need to see schemas), but provides no explicit guidance on when to choose this over sibling tools, nor any alternatives or exclusions. It's a basic 'use this to list schemas' with no deeper contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tables and views in the database.
| Name | Required | Description | Default |
|---|---|---|---|
| schema_name | No | Optional schema name filter (e.g. 'dbo', 'sales'). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as side effects, permissions, or result scope. It only states the action without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is concise and well-structured.
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?
The description lacks details about the output format (e.g., what fields are returned for each table/view). Given no output schema, this omission leaves the agent partially uninformed, though the simplicity of the task mitigates the gap.
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 schema already fully describes the only parameter (schema_name) with an example. The tool description adds no extra meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: listing tables and views in the database. It distinguishes from sibling tools like list_schemas and get_table_schema by focusing on tables/views.
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 explicit guidance on when to use this tool versus alternatives. It does not mention scenarios or prerequisites, 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.
Execute a custom read-only SELECT query against the SQL Server database.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | List of positional parameter values for query placeholders (?). | |
| sql_query | Yes | T-SQL SELECT query (e.g., "SELECT u.id, u.name, o.total FROM dbo.users u JOIN dbo.orders o ON u.id = o.user_id WHERE u.active = ?"). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must disclose behavioral traits. It mentions 'read-only', which is a key safety property. However, it does not elaborate on permission requirements, result size limits, or error behavior, leaving the agent with only the bare minimum. It covers the core but is not rich.
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 concise sentence that front-loads the core purpose. No wasted words; every term is meaningful. It achieves maximum clarity in minimal length.
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?
With an output schema available, return values are covered elsewhere. The description adequately covers the read-only nature and custom SELECT scope. However, it does not clarify when to prefer this over execute_sql, which is a significant sibling overlap, leaving a small gap in contextual completeness.
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 both parameters (sql_query and params) with examples and types. The description adds no additional parameter-level details, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (execute), the resource (SQL Server database), and the scope (custom read-only SELECT query). This distinguishes it from siblings like read_records (structured reads) and execute_sql (potentially non-SELECT operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying a custom read-only SELECT query, implying this is for ad-hoc reads not covered by structured tools like read_records. However, it does not explicitly state when not to use it or contrast with execute_sql, so it's clear but lacks exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read/Select records from a table with optional column selection, WHERE filtering, ordering, and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return (default: 100). | |
| offset | No | Row offset for pagination (default: 0). | |
| params | No | Parameter values for the WHERE clause placeholders. | |
| columns | No | Specific list of columns to retrieve. | |
| order_by | No | SQL ORDER BY expression (e.g., "id DESC"). | |
| table_name | Yes | Target table name. | |
| schema_name | No | Target schema name (default: 'dbo'). | dbo |
| where_clause | No | SQL WHERE clause expression (e.g., "status = ? AND created_at > ?"). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It communicates a read-only SELECT action, but it does not go beyond the name/verb to note any constraints, default limits, edge cases, or side-effect-free guarantees beyond the obvious read semantics.
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?
A single sentence that is front-loaded with the action 'Read/Select records from a table' and efficiently enumerates optional features without extra filler. Every clause adds relevant information.
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 8 parameters and existing output schema plus 100% schema coverage, the description covers the main capabilities but omits any mention of schema_name or default behaviors such as limit/offset defaults. It is adequate but not comprehensive enough to earn a higher 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 100%, so the baseline is 3. The description mentions column selection, filtering, ordering, and pagination, which align with several parameters, but it does not add details beyond what the input schema already provides for each parameter.
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 'Read/Select records from a table' with specific verb and resource, and enumerates capabilities such as column selection, WHERE filtering, ordering, and pagination. This differentiates it from siblings like read_query and execute_sql by scoping to table-based SELECT operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use: it is the tool to read records from a table using structured filters and options. It does not explicitly mention alternatives or exclusions, but the phrasing distinguishes it from free-form SQL tools like read_query and execute_sql.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update matching records in a table with specified values (Update).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Dictionary of column-value pairs to set (e.g., {"status": "ACTIVE", "updated_at": "2026-08-19"}). | |
| table_name | Yes | Target table name. | |
| schema_name | No | Target schema name (default: 'dbo'). | dbo |
| where_clause | Yes | SQL WHERE clause expression (required to avoid full table updates). | |
| where_params | No | Positional parameter values for the WHERE clause placeholders. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 'Update' which implies mutation, but it does not disclose that updates are permanent, that a where clause is required to avoid modifying all rows (the schema hints at this), or any other side effects. The description adds no behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but the parenthetical '(Update)' is redundant and adds no value. It is concise but not maximally clear or structured. Slight deduction for the tautological parenthetical.
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?
The tool has no annotations)Skip and an output schema exists, but the description provides no context about side effects, safety, or when to use it. It does not mention that it is a bulk update, requires caution, or any prerequisites like needing a where clause to avoid updating all rows. The schema does describe where_clause, but the description itself is too sparse to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions are thorough (100% coverage), including examples for data and clarifications for where_clause and where_params. The description does not add additional parameter semantics, but given the full schema descriptions, a baseline of 3 is appropriate.
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: 'Update matching records in a table with specified values'. The verb 'Update' and resource 'table' are specificlint. However, it doesn't differentiate from sibling tools like delete_records or insert_record, and the parenthetical '(Update)' adds redundancy.
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 on when to use this vs. alternatives like insert_records or delete_records. The description doesn't mention typical scenarios or prerequisites (e.g., needing to know the table schema). The where_clause requirement is in the schema but not in the description, so an agent might not know when to prefer this over execute_sql.
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.
v0.1.0bulk_insert_recordsdelete_recordsexecute_sqlget_database_schemaget_table_schemainsert_recordlist_schemaslist_tablesread_queryread_recordsupdate_recordsSeveral tools have overlapping boundaries: get_table_schema and get_database_schema overlap when filtering by table name, read_records and read_query both perform reads, and execute_sql can perform the same insert/update/delete operations as the dedicated CRUD tools. The descriptions help clarify intent, but an agent may still select the wrong tool in some scenarios.
The tools generally follow a consistent verb_noun snake_case pattern (list_tables, insert_record, update_records, delete_records). There is minor inconsistency between list, get, and read prefixes, but the naming remains predictable and easy to navigate.
11 tools is well-scoped for a SQL Server MCP server. The set includes schema discovery, table inspection, record reads, CRUD operations, bulk insertion, and raw SQL execution without feeling bloated.
The tool surface covers the core database lifecycle: listing schemas/tables, inspecting schema definitions, reading records, inserting, updating, deleting, bulk inserting, and executing DDL/DML. There are no obvious missing operations for typical SQL Server management and data access workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
GibsonAI MCP server: manage your databases with natural language
Official Microsoft MCP Server to query Microsoft Entra data using natural language
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Thiago-Fernandes-Dias/sql_server_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
