mcp-sql-querystore
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_SQL_PWD | No | The password directly (least preferred). | |
| MCP_SQL_UID | No | The SQL login username for SQL authentication. | |
| MCP_SQL_EXTRA | No | Additional connection string parameters. | |
| MCP_SQL_DRIVER | No | The ODBC driver name (e.g., 'ODBC Driver 18 for SQL Server'). | |
| MCP_SQL_SERVER | No | The SQL Server host and instance (e.g., yourhost\INSTANCE). Required when assembling from parts. | |
| MCP_SQL_ENCRYPT | No | Whether to encrypt the connection (e.g., 'yes' or 'no'). | |
| MCP_SQL_PWD_ENV | No | Name of another environment variable that contains the password. | |
| MCP_SQL_TRUSTED | No | Set to 'yes' to use integrated authentication (no password stored). Preferred for CJIS/PCI. | |
| MCP_SQL_DATABASE | No | The database name. | |
| MCP_SQL_PWD_FILE | No | Path to a file containing the password (vault-mounted file). | |
| MCP_SQL_TRUST_CERT | No | Whether to trust the server certificate. Set to 'yes' only for a self-signed/local cert; leave 'no' against instances with proper certificates. | |
| MCP_SQL_QUERY_TIMEOUT | No | Query timeout in seconds (default: 30, 0 disables). | 30 |
| MCP_SQL_CONNECT_TIMEOUT | No | Connection timeout in seconds (default: 10). | 10 |
| MCP_SQL_CONNECTION_STRING | No | The full connection string. Simplest; back-compat. Resolved first. | |
| MCP_SQL_CONNECTION_STRING_FILE | No | Path to a file holding the full connection string (Docker/K8s secret-mount style). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_regressed_queriesB | Detect queries whose performance regressed by comparing a recent period against an earlier baseline period from Query Store. |
| get_query_execution_planB | Fetch execution plan(s) for a Query Store query_id and return a compact summary (missing indexes, warnings, lookups) plus optional raw XML. |
| analyze_parameter_sniffingB | Detect queries whose runtime varies widely across multiple compiled plans — the classic parameter-sniffing signature. Ranks by the ratio of slowest to fastest plan mean duration. |
| get_missing_index_impactA | Aggregate missing-index recommendations found in Query Store plans, ranked by the optimizer's estimated impact score. Groups duplicate recommendations across queries. |
| get_wait_statsA | Aggregate query wait time by wait category over a time window — shows WHY queries are slow (CPU, blocking/locks, IO, memory, etc.) rather than which are slow. Ranked by total wait time. |
| sweep_regressionsA | Run regression detection across ALL online databases that have Query Store enabled, and return the worst regressions found per database. Use this to triage a whole instance instead of one database at a time. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a clearly distinct diagnostic angle: regression detection, execution plans, parameter sniffing, missing-index impact, wait stats, and an instance-wide sweep. The only near-overlap (get_regressed_queries vs sweep_regressions) is explicitly resolved by the descriptions distinguishing single-database vs all-database scope.
All six names follow a consistent snake_case verb_noun pattern (get_*, analyze_*, sweep_*). The verb variation is meaningful rather than chaotic, and the object of each name clearly signals its purpose.
Six tools is well within the ideal range and each one occupies a distinct slot in the Query Store diagnostic workflow. No tool feels redundant or filler.
The surface covers the core Query Store diagnostics lifecycle: regression detection, plan inspection, parameter sniffing, missing indexes, wait stats, and instance-wide triage. Minor gaps remain (e.g., retrieving query text or top-resource queries) but core agent workflows are fully supported.