de en es ja ko ru zh

SqlAugur

Name: SqlAugur
Author: mbentham

by mbentham

Overview Schema Source Related Servers Discussions Admin

Hybrid

SqlAugur

NuGet NuGet Downloads License: MIT .NET 10.0

An MCP server that gives AI assistants safe, read-only access to SQL Server databases. Every query is parsed into a full AST using Microsoft's official T-SQL parser — not regex — so comment injection, string literal tricks, and encoding bypasses are blocked at the syntax level.

┌──────────────┐          ┌───────────────────────────────────────────┐        ┌──────────────┐
│              │  stdio   │  SqlAugur                                 │        │              │
│  AI Client   │◄────────►│                                           │───────►│  SQL Server  │
│              │          │  ┌────────────┐  ┌──────────────────────┐ │        │              │
└──────────────┘          │  │  Query     │  │  Schema / Diagram /  │ │        └──────────────┘
                          │  │  Validator │  │  DBA Services        │ │
                          │  └────────────┘  └──────────────────────┘ │
                          │  ┌────────────────────────────────────┐   │
                          │  │  Rate Limiter                      │   │
                          │  └────────────────────────────────────┘   │
                          └───────────────────────────────────────────┘

Quick Start

Prerequisite: .NET 10.0 runtime

1. Install

dotnet tool install -g SqlAugur

2. Configure — create ~/.config/sqlaugur/appsettings.json (Linux/macOS) or %APPDATA%\sqlaugur\appsettings.json (Windows), setting the connection string for your environment:

{
  "SqlAugur": {
    "Servers": {
      "production": {
        "ConnectionString": "Server=myserver;Database=master;Integrated Security=True;TrustServerCertificate=False;Encrypt=True;"
      }
    }
  }
}

3. Connect — add to your MCP client:

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "sqlaugur": {
      "command": "sqlaugur"
    }
  }
}

claude mcp add --transport stdio sqlaugur -- sqlaugur

Or add to .mcp.json in your project root:

{
  "mcpServers": {
    "sqlaugur": {
      "type": "stdio",
      "command": "sqlaugur"
    }
  }
}

Add to .vscode/mcp.json in your workspace:

{
  "servers": {
    "sqlaugur": {
      "command": "sqlaugur"
    }
  }
}

4. Verify — ask your AI assistant to list_servers and you should see your configured connection.

For Docker, Podman, and other install methods, see Installation.

Related MCP server: mcp-sqlserver-readonly

Why This Approach

AST-level query validation — Most MCP database servers use keyword blocking or no validation at all. This project parses every query into a full syntax tree using Microsoft's official TSql180Parser. Comment injection, string literal tricks, and encoding bypasses are blocked at the syntax level, not with fragile regex patterns.
Rate limiting — Token bucket throughput limiting and concurrency control prevent runaway AI query loops from overwhelming production SQL Servers. No other MCP database server offers this.
DBA diagnostic tooling — Integrated support for First Responder Kit, DarlingData, and sp_WhoIsActive with parameter blocking that prevents write operations. This is an entirely new MCP capability category.
Response size optimisation — DBA tools exclude verbose columns (XML query plans, deadlock graphs, metric breakdowns) and truncate long strings by default, reducing response sizes by 90–99%. Use verbose and includeQueryPlans parameters to get full untruncated output when needed.
Progressive discovery — Up to 29 tools organized into toolsets that load on demand. Only 6 core tools are exposed initially, keeping the AI's context window small and reducing token usage. Additional toolsets are discovered and enabled as needed.

Features

Security

Read-only by design — only SELECT and CTE queries are permitted
AST-based query validation using ScriptDom (not regex)
Parameter blocking on all diagnostic stored procedures to prevent writes
Concurrency and throughput rate limiting

Database Tooling

Multi-server support — named connections to multiple SQL Server instances
Schema overview — concise Markdown schema maps with PKs, FKs, constraints, and defaults
Table documentation — Markdown descriptions of columns, indexes, foreign keys, and constraints
ER diagram generation — PlantUML and Mermaid diagrams with smart cardinality detection
Schema exploration — list programmable objects, view definitions, extended properties, dependency graphs
Query plan analysis — estimated or actual XML execution plans
DBA diagnostics — optional integration with First Responder Kit, DarlingData, and sp_WhoIsActive with automatic response size optimisation
Progressive discovery — dynamic toolset mode reduces initial context window usage by exposing tools on demand

Installation

All methods produce the same MCP server.

NuGet Global Tool (recommended)

Prerequisite: .NET 10.0 runtime

dotnet tool install -g SqlAugur

Create your configuration file:

# Linux/macOS
mkdir -p ~/.config/sqlaugur
# Edit ~/.config/sqlaugur/appsettings.json with your server connections

# Windows (PowerShell)
mkdir "$env:APPDATA\sqlaugur" -Force
# Edit %APPDATA%\sqlaugur\appsettings.json with your server connections

MCP client configuration:

{
  "mcpServers": {
    "sqlserver": {
      "command": "sqlaugur"
    }
  }
}

To update: dotnet tool update -g SqlAugur

Docker / Podman

# Volume-mount a config file
docker run -i --rm \
  -v /path/to/appsettings.json:/app/appsettings.json:ro,Z \
  ghcr.io/mbentham/sqlaugur:latest

# Or use environment variables (no config file needed)
docker run -i --rm \
  -e SqlAugur__Servers__production__ConnectionString="Server=host.docker.internal;Database=master;..." \
  ghcr.io/mbentham/sqlaugur:latest

Note: To reach a SQL Server on the host machine, use host.docker.internal (Docker Desktop) or --network=host (Linux). Replace docker with podman — all commands are identical. The :Z flag on volume mounts is required for SELinux-enabled systems (Fedora, RHEL); Docker Desktop users on macOS/Windows can omit it.

MCP client configuration:

{
  "mcpServers": {
    "sqlserver": {
      "command": "docker",
      "args": ["run", "-i", "--rm",
        "-v", "/path/to/appsettings.json:/app/appsettings.json:ro,Z",
        "ghcr.io/mbentham/sqlaugur:latest"]
    }
  }
}

services:
  sqlaugur:
    image: ghcr.io/mbentham/sqlaugur:latest
    stdin_open: true
    volumes:
      - ./appsettings.json:/app/appsettings.json:ro,Z

MCP client configuration:

{
  "mcpServers": {
    "sqlserver": {
      "command": "docker",
      "args": ["compose", "run", "-i", "--rm", "sqlaugur"]
    }
  }
}

Build from Source

Prerequisite: .NET 10.0 SDK

git clone git@github.com:mbentham/SqlAugur.git
cd SqlAugur
dotnet publish SqlAugur -c Release -o SqlAugur/publish
cp SqlAugur/appsettings.example.json SqlAugur/publish/appsettings.json
# Edit SqlAugur/publish/appsettings.json with your server connections

MCP client configuration:

{
  "mcpServers": {
    "sqlserver": {
      "command": "dotnet",
      "args": ["/absolute/path/to/SqlAugur/publish/SqlAugur.dll"]
    }
  }
}

Configuration

The server loads configuration from multiple sources. Higher-priority sources override lower ones:

Command-line arguments
Environment variables — using __ as section delimiter (e.g., SqlAugur__Servers__production__ConnectionString=...)
Current working directory — appsettings.json in the directory you run the command from
User config directory — ~/.config/sqlaugur/appsettings.json on Linux, %APPDATA%\sqlaugur\appsettings.json on Windows
Azure Key Vault — when AzureKeyVaultUri is set (see below)
App directory — appsettings.json next to the DLL

Example configuration (Windows Authentication — recommended):

{
  "SqlAugur": {
    "Servers": {
      "production": {
        "ConnectionString": "Server=myserver;Database=master;Integrated Security=True;TrustServerCertificate=False;Encrypt=True;"
      }
    },
    "MaxRows": 1000,
    "CommandTimeoutSeconds": 30,
    "MaxConcurrentQueries": 5,
    "MaxQueriesPerMinute": 60,
    "EnableFirstResponderKit": false,
    "EnableDarlingData": false,
    "EnableWhoIsActive": false,
    "EnableDynamicToolsets": false
  }
}

Option	Default	Description
`Servers`	—	Named SQL Server connections (name → connection string)
`MaxRows`	1000	Maximum rows returned per query
`CommandTimeoutSeconds`	30	SQL command timeout for all queries and procedures
`MaxConcurrentQueries`	5	Maximum number of SQL queries that can execute concurrently
`MaxQueriesPerMinute`	60	Maximum queries allowed per minute (token bucket rate limit)
`EnableFirstResponderKit`	false	Enable First Responder Kit diagnostic tools (sp_Blitz, sp_BlitzFirst, sp_BlitzCache, sp_BlitzIndex, sp_BlitzWho, sp_BlitzLock)
`EnableDarlingData`	false	Enable DarlingData diagnostic tools (sp_PressureDetector, sp_QuickieStore, sp_HealthParser, sp_LogHunter, sp_HumanEventsBlockViewer, sp_IndexCleanup, sp_QueryReproBuilder)
`EnableWhoIsActive`	false	Enable sp_WhoIsActive session monitoring
`EnableDynamicToolsets`	false	Enable progressive tool discovery — DBA tools load on demand via 3 meta-tools instead of at startup. Reduces initial context window usage. The `Enable*` flags still control which toolsets are allowed.
`AzureKeyVaultUri`	—	Azure Key Vault URI (e.g., `https://myvault.vault.azure.net/`). When set, secrets from the vault are added as a configuration source using `DefaultAzureCredential`. Key Vault secret names use `--` as a section separator (e.g., a secret named `SqlAugur--Servers--prod--ConnectionString` maps to `SqlAugur:Servers:prod:ConnectionString`).

Security Note: appsettings.json is gitignored to prevent accidental credential commits. See SECURITY.md for recommended authentication methods including Windows Authentication, Azure Managed Identity, and secure credential storage options.

Tools

The server provides 30 tools organized into toolsets. Six core tools are always available. Additional toolsets are loaded at startup (static mode) or on demand (dynamic mode).

Core Tools

Tool	Description
`list_servers`	Lists available SQL Server instances configured in `appsettings.json`.
`list_databases`	Lists all databases on a named server with names, IDs, states, and creation dates.
`read_data`	Executes a read-only SQL SELECT query. Only `SELECT` and `WITH` (CTE) queries are allowed. Results returned as JSON with a configurable row limit.
`get_query_plan`	Returns the estimated or actual XML execution plan for a SELECT query.
`get_schema_overview`	Concise Markdown schema overview: tables, columns, PKs, FKs, unique/check constraints, defaults. Supports `compact` mode, schema and table filtering.
`describe_table`	Comprehensive table metadata in Markdown: columns, data types, nullability, defaults, identity, computed expressions, indexes, FKs, constraints.

Tool	Description
`list_programmable_objects`	Lists views, stored procedures, functions, and triggers. Filterable by type and schema.
`get_object_definition`	Returns the source definition (CREATE statement) of a programmable object.
`get_extended_properties`	Reads extended properties (descriptions, metadata) on tables, columns, and other objects.
`get_object_dependencies`	Shows what an object references and what references it — upstream and downstream dependency graphs.

Tool	Description
`get_plantuml_diagram`	Generates a PlantUML ER diagram with tables, columns, PKs, and FK relationships. Saves to a `.puml` file. Supports `compact` mode, schema/table filtering, and a configurable table limit (max 200).
`get_mermaid_diagram`	Generates a Mermaid ER diagram with tables, columns, PKs, and FK relationships. Saves to a `.mmd` file. Supports `compact` mode, schema/table filtering, and a configurable table limit (max 200).

DBA Diagnostic Tools

Each toolkit is enabled independently via config flags and requires the corresponding stored procedures installed on the target SQL Server.

All DBA tools apply response size optimisation by default — XML query plan columns are excluded and long string values are truncated to keep responses within AI context window limits. Every tool supports these optional parameters:

Parameter	Description
`verbose`	Return all columns with no truncation.
`includeQueryPlans`	Include XML execution plan columns in the output.
`maxRows`	Maximum rows to return per result set. Available on tools with variable-length output: BlitzIndex, BlitzLock, HealthParser, LogHunter (default 200), IndexCleanup, QueryReproBuilder.

Some tools have additional parameters: includeXmlReports (BlitzLock, HealthParser, HumanEventsBlockViewer), compact (sp_WhoIsActive), verboseMetrics (QuickieStore).

Install from: github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit

Tool	Description
`sp_blitz`	Overall SQL Server health check — prioritized findings for performance, configuration, and security.
`sp_blitz_first`	Real-time performance diagnostics — samples DMVs over an interval for waits, file latency, and perfmon counters.
`sp_blitz_cache`	Plan cache analysis — top queries by CPU, reads, duration, executions, or memory grants.
`sp_blitz_index`	Index analysis — missing, unused, and duplicate indexes with usage patterns.
`sp_blitz_who`	Active query monitor — what's running, blocking info, tempdb usage, query plans.
`sp_blitz_lock`	Deadlock analysis from the `system_health` extended event session.
`sp_blitz_plan_compare`	Cross-server query plan comparison — captures a plan snapshot on one server and compares it to the cached plan on a second server without using linked servers. Requires the demon_hunters branch until merged to main.

Install from: github.com/erikdarling/DarlingData

Tool	Description
`sp_pressure_detector`	Diagnoses CPU and memory pressure — resource bottlenecks, high-CPU queries, memory grants, disk latency.
`sp_quickie_store`	Query Store analysis — top resource-consuming queries, plan regressions, wait statistics.
`sp_health_parser`	Parses the `system_health` extended event session for historical waits, disk latency, CPU, memory, and locking.
`sp_log_hunter`	Searches SQL Server error logs for errors, warnings, and custom messages.
`sp_human_events_block_viewer`	Analyzes blocking events from `sp_HumanEvents` sessions — blocking chains, lock details, waits.
`sp_index_cleanup`	Finds unused and duplicate indexes that are candidates for removal.
`sp_query_repro_builder`	Generates reproduction scripts for Query Store queries with parameter values.

Install from: whoisactive.com

Tool	Description
`sp_whoisactive`	Monitors active sessions and queries — wait info, blocking details, tempdb usage, resource consumption.

Progressive Discovery

When EnableDynamicToolsets is true, only core tools load at startup. Three meta-tools let the AI discover and enable additional toolsets on demand, reducing initial context window usage:

Tool	Description
`list_toolsets`	Lists available toolsets with status (available, enabled, not configured) and tool counts.
`get_toolset_tools`	Returns detailed tool and parameter info for a specific toolset before enabling it.
`enable_toolset`	Enables a toolset, making its tools available. Only works if the admin has enabled the toolset via the corresponding `Enable*` config flag.

Example flow:

AI calls list_toolsets — sees first_responder_kit is "available" (configured but not yet enabled)
AI calls get_toolset_tools("first_responder_kit") — reviews the 6 tools and their parameters
AI calls enable_toolset("first_responder_kit") — the 6 tools are now registered and usable
AI calls sp_blitz — runs the health check as normal

In static mode (EnableDynamicToolsets: false), all enabled toolsets load at startup and the discovery tools are not registered. Schema Exploration and Diagrams toolsets are always loaded regardless of mode.

Known limitation: Progressive discovery relies on the MCP notifications/tools/list_changed notification to inform clients that new tools have been registered. Claude Code does not currently handle this notification (anthropics/claude-code#4118), so dynamically enabled toolsets will not appear. Use static mode (EnableDynamicToolsets: false) when using Claude Code.

Security

Query Validation

Every query is parsed into an Abstract Syntax Tree (AST) using Microsoft's official TSql180Parser and must pass these rules:

Single statement only — multiple statements are rejected
SELECT only — INSERT, UPDATE, DELETE, DROP, EXEC, CREATE, ALTER, and all other statement types are blocked
No SELECT INTO — prevents table creation via SELECT
No external data access — OPENROWSET (all variants including BULK, Cosmos DB, and internal), OPENQUERY, OPENDATASOURCE, OPENXML blocked
No linked servers — four-part name references are rejected
No MAXRECURSION hint — prevents overriding the default recursion limit
Cross-database queries are allowed — three-part names work by design; the security boundary is the server, not the database. To restrict to a single database, limit the login's permissions.

Because validation operates on the parsed AST, it correctly handles edge cases that defeat string-based approaches: keywords inside comments, string literals, nested block comments, and encoding tricks.

Parameter Blocking

Diagnostic stored procedures execute via whitelisted procedure names with blocked parameters that prevent writes:

First Responder Kit — all @Output* parameters blocked (prevents writing results to server tables)
DarlingData — logging and output parameters blocked (prevents table creation and data retention)
sp_WhoIsActive — @destination_table, @return_schema, @schema, @help blocked

Rate Limiting

All tool executions are subject to concurrency limiting (MaxConcurrentQueries, default 5) and throughput limiting (MaxQueriesPerMinute, default 60). Excess requests are rejected with a retry message.

Connection Security

Use Windows Authentication or Azure Managed Identity where possible to avoid storing credentials in config files. When SQL Authentication is required, use environment variable overrides to inject credentials at runtime. See SECURITY.md for detailed guidance including credential stores and connection string encryption.

Known Risks

This project depends on the official Microsoft MCP C# SDK (ModelContextProtocol NuGet package, version 1.2.0). As the MCP framework handles all protocol I/O, any vulnerability in it directly affects this application's security boundary. Monitor the package for updates and upgrade when new versions are released.
The data returned from a SQL Server query could include malicious prompt injection targeting AIs. This is a risk of all AI use and cannot be mitigated by this project. Ensure you're following best practices for AI security and only connecting to trusted data sources.

Contributing

Contributions are welcome. See CONTRIBUTING.md for architecture details, development setup, testing instructions, and guidelines for adding new tools.

License

MIT

Available Tools

12 tools

describe_tableDescribe Table StructureA

Read-onlyIdempotent

Get comprehensive metadata about a single table including columns, data types, indexes, primary key, foreign keys, check constraints, and default constraints.

Name	Required	Description	Default
`tableName`	Yes	Name of the table to describe
`schemaName`	No	Schema name (default 'dbo')	dbo
`serverName`	Yes	Name of the SQL Server to query (use list_servers to see available names)
`databaseName`	Yes	Name of the database to query (use list_databases to see available databases)

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is clear. The description adds useful detail on the metadata returned (indexes, foreign keys, etc.), which goes beyond annotations and helps the agent understand the scope.

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

Conciseness5/5

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

Single sentence of 23 words, front-loaded with the core action and resource, no wasted words.

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

Completeness4/5

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

Given 4 parameters, high schema coverage, and no output schema, the description adequately lists the metadata types returned and mentions prerequisite tools. It is complete enough for an AI agent to understand the tool's purpose and usage.

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?

Input schema covers 100% of parameters with descriptions, including tips to use sibling tools for server/database names. The tool description does not add further meaning beyond what the schema provides, so baseline 3 is appropriate.

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

Purpose5/5

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

Description clearly states 'Get comprehensive metadata about a single table' and lists specific elements (columns, data types, indexes, etc.), distinguishing it from siblings like get_schema_overview or read_data.

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?

Does not explicitly state when to use versus alternatives like get_schema_overview or get_mermaid_diagram. It hints at prerequisites by referencing list_servers and list_databases, but lacks clear usage context for an AI agent.

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

get_extended_propertiesGet Extended PropertiesA

Read-onlyIdempotent

Read extended properties (descriptions, metadata) from tables and columns. Returns JSON with schema, table, column, property name, and value.

Name	Required	Description
`tableName`	No	Optional table name filter
`columnName`	No	Optional column name filter
`schemaName`	No	Optional schema name filter
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds that it returns JSON with specific fields, but does not disclose further behavioral details (e.g., permissions, error behavior).

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?

Two sentences with no redundancy. The action and output are stated upfront.

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

Completeness4/5

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

For a simple read tool with good annotations and schema, the description covers the core purpose and output. Some missing context like error handling or typical use, but adequate.

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%, so parameters are well-documented. The description adds no additional meaning beyond the schema definitions.

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

Purpose5/5

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

The description clearly states it reads extended properties from tables and columns, specifying the output fields. This distinguishes it from siblings like describe_table or get_object_definition.

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?

No explicit guidance on when to use vs. alternatives. The description implies usage for retrieving metadata, but does not mention exclusions or when to prefer other tools.

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

get_mermaid_diagramGet Mermaid ER DiagramA

Generate a Mermaid ER diagram saved to a file. Shows tables, columns, PKs, and FK relationships with smart cardinality.

Name	Required	Description
`compact`	No	true/false. Show only PK/FK columns without non-key columns
`maxTables`	No	Max tables to include (1-200, default 50)
`outputPath`	Yes	File path for output (e.g. '/tmp/diagram.mmd')
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`excludeTables`	No	Optional comma-separated tables to exclude. Ignored if includeTables set.
`includeTables`	No	Optional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
`excludeSchemas`	No	Optional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
`includeSchemas`	No	Optional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations indicate readOnlyHint=false and idempotentHint=false, which aligns with the description's mention of saving a file (write operation). However, the description adds no further behavioral details, such as overwrite behavior or prerequisites.

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 sentence that is concise, front-loaded, and contains no unnecessary words. It efficiently conveys the core functionality.

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 complexity (9 parameters, no output schema), the description is adequate but not comprehensive. It lacks details about the output format, error conditions, or behavior with omitted parameters.

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 fully documents all 9 parameters with descriptions. The tool's description does not add any additional semantics beyond what is already in the schema.

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 explicitly states the tool generates a Mermaid ER diagram, saves it to a file, and shows tables, columns, PKs, and FK relationships. It clearly distinguishes from sibling tools like get_plantuml_diagram.

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 explicit guidance on when to use this tool versus alternatives (e.g., PlantUML diagram). The description implies its purpose but does not provide usage context or exclusions.

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

get_object_definitionGet Object DefinitionA

Read-onlyIdempotent

Get the T-SQL source code of a stored procedure, function, view, or trigger. Returns Markdown with the object type and definition.

Name	Required	Description	Default
`objectName`	Yes	Object name (e.g. 'usp_GetOrders')
`schemaName`	No	Schema name (default 'dbo')	dbo
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds that output is Markdown with object type and definition, but does not disclose other behaviors like error handling, permission requirements, or performance impact.

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?

Two sentences, no unnecessary words. Efficiently conveys purpose and output format.

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?

With all parameters documented and no output schema needed, the description sufficiently describes the return format (Markdown with object type and definition). Could mention error cases like missing object, but overall adequate for a simple retrieval tool.

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 descriptions for each parameter (e.g., serverName from list_servers, objectName with example). The description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states it retrieves T-SQL source code for specific object types (stored procedure, function, view, trigger) and returns Markdown with object type and definition, distinguishing it from sibling tools like describe_table or get_query_plan.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it is for retrieving source code, but does not mention scenarios where it should not be used or suggest alternative tools.

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

get_object_dependenciesGet Object DependenciesA

Read-onlyIdempotent

Show what a database object references and what references it. Returns JSON with 'references' and 'referencedBy' arrays for dependency analysis.

Name	Required	Description	Default
`objectName`	Yes	Object name (e.g. 'vw_ActiveProducts')
`schemaName`	No	Schema name (default 'dbo')	dbo
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds value by specifying the output format ('references' and 'referencedBy' arrays), going beyond annotations.

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 two sentences, front-loads the action, and provides key output details. No unnecessary words.

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

Completeness5/5

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

Given the tool's complexity (dependency analysis), the input schema is fully described, and the output is explained. Sibling tools provide context, and no missing information is critical.

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 each parameter has a description. The tool description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb ('Show what...references') and clearly identifies the resource (database object dependencies). It distinguishes from siblings like get_object_definition and describe_table by focusing on dependencies.

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

Usage Guidelines3/5

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

The description implies usage for dependency analysis but does not explicitly state when to use this tool vs alternatives like get_object_definition. No exclusions or contexts are provided.

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

get_plantuml_diagramGet Database ER DiagramA

Generate a PlantUML ER diagram saved to a file. Shows tables, columns, PKs, and FK relationships with smart cardinality.

Name	Required	Description
`compact`	No	true/false. Show only PK/FK columns without data types
`maxTables`	No	Max tables to include (1-200, default 50)
`outputPath`	Yes	File path for output (e.g. '/tmp/diagram.puml')
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`excludeTables`	No	Optional comma-separated tables to exclude. Ignored if includeTables set.
`includeTables`	No	Optional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
`excludeSchemas`	No	Optional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
`includeSchemas`	No	Optional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.

TDQS

A3.8/5.0

Behavior3/5

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

Discloses file-saving side effect, consistent with readOnlyHint=false. Does not elaborate on overwrite behavior, permissions, or other traits beyond what annotations already indicate.

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?

Two short sentences packed with essential purpose and content. No wasted words. Front-loaded.

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

Completeness4/5

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

Reasonably complete for a diagram generation tool with no output schema. Could clarify that no result content is returned beyond file write. Otherwise covers key behavior.

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?

All 9 parameters have descriptions in schema (100% coverage), so description adds no new parameter meaning beyond the schema. Baseline score 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?

Clearly states it generates a PlantUML ER diagram and saves to file, mentioning key content (tables, columns, PKs, FK relationships). Distinguishes from sibling get_mermaid_diagram and describe_table.

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

Usage Guidelines3/5

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

No explicit guidance on when to use vs. alternatives like get_mermaid_diagram. Implies usage for ER diagram generation but lacks when-not-to-use or selection criteria.

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

get_query_planGet Query Execution PlanA

Idempotent

Get the estimated or actual XML execution plan for a SELECT query. Estimated plans show the optimizer's plan without executing. Actual plans execute the query and include runtime statistics. Uses the same query validation as read_data (SELECT only).

Name	Required	Description	Default
`query`	Yes	SQL SELECT query to get the execution plan for. Only SELECT and WITH (CTE) queries are permitted.
`planType`	No	Plan type: 'estimated' (default, does not execute) or 'actual' (executes the query)	estimated
`outputPath`	Yes	File path for output (e.g. '/tmp/plan.sqlplan')
`serverName`	Yes	Name of the SQL Server to query (use list_servers to see available names)
`databaseName`	Yes	Name of the database to query (use list_databases to see available databases)

TDQS

A4.2/5.0

Behavior4/5

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

With readOnlyHint=false and idempotentHint=true already declared, the bar is lower, and the description adds the important disclosure that 'actual' plans actually execute the query and return runtime stats — a genuine side-effect warning beyond the annotations. It doesn't cover permissions, plan size/cost, or that the result is written to a file, so it stops short of fully rich behavioral context.

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?

Three tight sentences: purpose first, then the estimated/actual tradeoff, then the query restriction. Nothing is redundant and the most decision-relevant fact (whether the query executes) is front-loaded.

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

Completeness4/5

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

There is no output schema, so the description carries some return-value burden, and it does say the plan is an XML plan — but it never mentions that the plan is written to the required outputPath file. That omission is a modest gap rather than a serious one, since the parameter is required and self-describing.

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%, so every parameter is already documented, including planType's estimated/actual semantics and the SELECT/WITH restriction on query. The description reinforces planType behavior but adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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

Purpose5/5

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

The description states a specific verb and resource ('Get the estimated or actual XML execution plan') and immediately distinguishes the two modes the tool supports. It also anchors itself in the family by noting it shares query validation with read_data, so an agent can place it relative to siblings.

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

Usage Guidelines4/5

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

It clearly explains the choice between modes: estimated plans don't execute, actual plans execute and add runtime statistics, and only SELECT/WITH queries are permitted. It doesn't explicitly say when to prefer this over read_data or describe_table, but the mode-selection guidance is strong practical context.

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

get_schema_overviewGet Database Schema OverviewA

Read-onlyIdempotent

Markdown overview of database schema: tables, columns, types, PKs, FKs, unique/check constraints, defaults. Use get_plantuml_diagram for visual ER output or describe_table for single-table detail.

Name	Required	Description
`compact`	No	true/false. Show only PK/FK columns without data types
`maxTables`	No	Max tables to include (1-200, default 50)
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`excludeTables`	No	Optional comma-separated tables to exclude. Ignored if includeTables set.
`includeTables`	No	Optional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
`excludeSchemas`	No	Optional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
`includeSchemas`	No	Optional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint and idempotentHint. The description adds that the output is a Markdown overview including constraints and defaults, which is consistent and provides further behavioral context beyond the annotations.

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?

Two sentences, no wasted words. The critical information (output format, content, alternatives) is front-loaded.

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

Completeness4/5

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

For an 8-parameter tool with full schema coverage and no output schema, the description covers the essential purpose and alternatives well. However, it could briefly note that filtering parameters allow narrowing the overview, but that is implicitly clear from the 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 input schema already documents all parameters thoroughly. The description does not reiterate parameter meanings but adds high-level context about what the tool returns. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states 'Markdown overview of database schema' with specific details (tables, columns, types, PKs, FKs, etc.). It also distinguishes from siblings by recommending get_plantuml_diagram for visual ER and describe_table for single-table detail.

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

Usage Guidelines5/5

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

The description explicitly provides when-to-use guidance: 'Use get_plantuml_diagram for visual ER output or describe_table for single-table detail.' This helps the agent choose correctly among siblings.

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

list_databasesList Databases on SQL ServerA

Read-onlyIdempotent

List all databases on a named SQL Server instance. Returns database names, IDs, states, and creation dates. Use list_servers first to discover available server names.

Name	Required	Description	Default
`serverName`	Yes	Name of the SQL Server to query (use list_servers to see available names)

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare read-only and idempotent. Description adds return field details and prerequisite, complementing annotations without contradiction.

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?

Two sentences, front-loaded with action and purpose, no redundant words. Highly 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?

For a simple list tool with one parameter, description covers return fields, prerequisite, and action. No output schema but return info is stated. Sufficiently complete.

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 a clear parameter description. Description adds use-case context (list_servers prerequisite) but not much beyond schema. Baseline 3 is appropriate.

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

Purpose5/5

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

Describes specific verb 'List' and resource 'databases on SQL Server', lists return fields, and distinguishes from sibling by mentioning prerequisite 'list_servers'.

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

Usage Guidelines4/5

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

Explicitly states to use list_servers first to discover server names, providing clear guidance on when to use this tool. No need for exclusions given simplicity.

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

list_programmable_objectsList Programmable ObjectsA

Read-onlyIdempotent

List stored procedures, functions, views, and triggers in a database. Returns JSON with schema, name, type, and create/modify dates.

Name	Required	Description
`serverName`	Yes	Server name from list_servers
`objectTypes`	No	Optional comma-separated object types to filter: PROCEDURE, FUNCTION, VIEW, TRIGGER
`databaseName`	Yes	Database name from list_databases
`excludeSchemas`	No	Optional comma-separated schemas to exclude (e.g. 'sys,INFORMATION_SCHEMA'). Ignored if includeSchemas set.
`includeSchemas`	No	Optional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the output is JSON with schema, name, type, and dates, providing context beyond annotations.

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 with no wasted words, front-loading the purpose and output format.

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

Completeness4/5

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

Given no output schema, the description covers return structure adequately. It lacks minor context like behavior when no objects found, but is sufficient for use.

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 baseline is 3. The description does not add meaning beyond what the schema already provides for each parameter.

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

Purpose5/5

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

The description clearly states the tool lists stored procedures, functions, views, and triggers in a database, specifying the exact resource and action. This distinguishes it from sibling tools like get_object_definition or describe_table.

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

Usage Guidelines3/5

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

The description implies usage for listing programmable objects but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

list_serversList SQL ServersA

Read-onlyIdempotent

List the available SQL Server instances that can be queried. Call this first to discover server names before using read_data.

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds no extra behavioral details. It confirms the read-only nature but nothing beyond that.

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?

Two short sentences, no wasted words. Front-loaded with key action and purpose.

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

Completeness5/5

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

For a zero-parameter, read-only tool with no output schema, the description covers what's needed: what it does (list servers) and when to use it (first).

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

Parameters4/5

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

No parameters in schema, so description doesn't need to add any. Rule: 0 params = baseline 4.

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

Purpose5/5

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

Description clearly states it lists available SQL Server instances and positions itself as the first call for discovery. It distinguishes from sibling tools by specifying this is the initial step before using read_data.

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

Usage Guidelines4/5

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

Explicitly instructs to call this first before read_data, providing clear usage context. Does not mention when not to use or alternatives, but the directive is sufficient for this simple tool.

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

read_dataRead Data from SQL ServerA

Read-onlyIdempotent

Execute a read-only SQL SELECT query against a named SQL Server instance. Only SELECT and WITH (CTE) queries are allowed. Use list_servers first to discover available server names. Small results are returned inline as JSON {truncated, rows}. Large results (over the configured row threshold, 500 by default, or about 40,000 characters) are written to a CSV file instead, and the response gives the file path, row count, column names and types, and a 10-row preview. Process a result file with code (e.g. Python csv/pandas, PowerShell Import-Csv) rather than reading it into context.

Name	Required	Description
`query`	Yes	SQL SELECT query to execute. Only SELECT and WITH (CTE) queries are permitted.
`toFile`	No	Write the full result to a CSV file and return its path and a preview, whatever its size. Use when the rows will be processed with code.
`serverName`	Yes	Name of the SQL Server to query (use list_servers to see available names)
`databaseName`	Yes	Name of the database to query (use list_databases to see available databases)

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, idempotentHint), but the description goes well beyond them: it discloses the row threshold (~500 rows / ~40,000 chars) that triggers CSV output, the exact response shapes (JSON {truncated, rows} vs. file path + row count + column names/types + 10-row preview), and instructs the agent to process files with code rather than into context. This is exactly the operational context an agent needs.

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?

Front-loaded with purpose and constraint, then prerequisites, then the two return paths in order of relevance. Every sentence carries distinct information (constraint, prerequisite, small-result shape, large-result shape, downstream handling) with no filler.

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

Completeness5/5

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

With no output schema present, the description carries the return-value burden and does so fully, describing both the inline JSON and CSV-file response formats plus guidance on handling each. Nothing an agent needs to call this correctly and interpret results is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the automatic large-result-to-file fallback (whose threshold the schema's toFile description doesn't mention) and by reiterating the SELECT/WITH restriction on query. It meaningfully clarifies the consequence of toFile above what the schema states.

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?

States a specific verb (execute) and resource (read-only SELECT against a named SQL Server instance) plus the hard constraint that only SELECT/WITH queries are permitted. This clearly separates it from siblings like describe_table, get_object_definition, and get_query_plan, which inspect schema/definitions rather than return rows.

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

Usage Guidelines4/5

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

Gives concrete prerequisites and routing ("Use list_servers first", "use list_databases to see available databases") and tells the agent when to prefer toFile and to process large results with code. It does not explicitly contrast against sibling tools that also read data, but the when-to-use context is clear.

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

Tool Schema Changelog

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

1 tool updatev1.7.0Oct 18, 2026

Changedread_data1 field changed

addedInput schema / properties / toFile

Added value: +{
+  "default": false,
+  "description": "Write the full result to a CSV file and return its path and a preview, whatever its size. Use when the rows will be processed with code.",
+  "type": "boolean"
+}

5 tool updatesv1.4.0May 7, 2026
- Changedget_extended_properties3 fields changed
  - changedInput schema / properties / columnName / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / schemaName / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / tableName / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedget_mermaid_diagram4 fields changed
  - changedInput schema / properties / excludeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / excludeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedget_plantuml_diagram4 fields changed
  - changedInput schema / properties / excludeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / excludeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedget_schema_overview4 fields changed
  - changedInput schema / properties / excludeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / excludeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedlist_programmable_objects3 fields changed
  - changedInput schema / properties / excludeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / objectTypes / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
12 tool updatesv1.3.1Feb 20, 2026
- First observeddescribe_table
- First observedget_extended_properties
- First observedget_mermaid_diagram
- First observedget_object_definition
- First observedget_object_dependencies
- First observedget_plantuml_diagram
- First observedget_query_plan
- First observedget_schema_overview
- First observedlist_databases
- First observedlist_programmable_objects
- First observedlist_servers
- First observedread_data

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4/5.0

Scored 2026-10-18 12:10 across 12 tools

Disambiguation4/5

Most tools are clearly distinguished by resource and action (server, database, table, programmable object, query plan). The two diagram generators, get_plantuml_diagram and get_mermaid_diagram, overlap heavily in purpose and could cause misselection, though their output formats differ.

Naming Consistency4/5

Names use consistent snake_case and mostly follow a get_/list_ verb_noun pattern. Exceptions like read_data and describe_table are minor deviations that remain readable and predictable.

Tool Count5/5

12 tools is well within the appropriate range for a SQL Server exploration and metadata server. Each tool covers a distinct concern without obvious bloat or unnecessary duplication.

Completeness4/5

The surface covers core read-only SQL Server exploration: servers, databases, queries, query plans, table metadata, schema overview, diagrams, dependencies, and programmable objects. Minor gaps exist, such as no explicit list_tables primitive, but get_schema_overview and describe_table provide workarounds.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

AI2SQLOAuth
io.ai2sql
Text-to-SQL MCP server: read-only queries on PostgreSQL, MySQL and SQL Server with your real schema
Databases Developer Tools
1
https://builder.ai2sql.io/api/chatgpt-mcp
SQL Server MCP by InsightfulPipe AOAuth
com.insightfulpipe
Hosted SQL Server MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
Databases Developer Tools
41
https://mssql.insightfulmcp.com/
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
https://mcp.classquill.com/mcp
sixta-connect AOAuth
ai.sixta
DBRE-grade SQL analysis inside any MCP client. No connection. No install. Paste a query.
Databases Code Analysis
132
https://connect.sixta.ai/mcp

Related MCP Servers

sql-explorer-mcp
Databases Search
govern-agents
A
license
Not graded
quality
F
maintenance
Read-only MCP server for SQL databases (SQL Server, Postgres, SQLite) with multi-server support and three-layer safety using AST validation and linting.
Updated 3 months ago (2026-07-29 13:07 UTC)
MIT
mcp-sqlserver-readonly
Databases Developer Tools
gbfeliped
A
license
Not graded
quality
D
maintenance
Read-only SQL Server MCP server enabling safe database queries, table listing, and schema inspection with built-in security protections.
Updated 4 months ago (2026-06-18 13:49 UTC)
MIT
MSSQL MCP Python Server
Databases Observability
lorenzouriel
A
license
Not graded
quality
A
maintenance
MCP server for safely exposing SQL Server database capabilities to LLM clients, with read-only mode, security features, and observability.
Updated 17 days ago (2026-10-13 00:24 UTC)
29
MIT
MSSQL-MCP
Databases Search
esasiyun17
A
license
A
quality
C
maintenance
Security-first, read-only MCP server for Microsoft SQL Server, enabling safe natural-language querying of databases.
Updated 4 months ago (2026-07-06 17:04 UTC)
5
4 npm
MIT