Skip to main content
Glama
deepeshd87

mcp-sql-querystore

by deepeshd87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

mcp-sql-querystore

Read-only MCP server exposing SQL Server Query Store diagnostics to LLM agents.

Six read-only diagnostic tools over Query Store, DMVs, and execution plans. The tools have been validated against a live SQL Server instance and are covered by a unit + integration test suite. Still validate against a non-prod instance of your own before pointing it at production, especially on SQL Server versions other than those noted under caveats.

Quickstart

  1. Provision a read-only login. Run provisioning/create_readonly_login.sql against your instance (edit names first). This login's permissions are the read-only guarantee — see the security model below.

  2. Install. pip install -e . in a virtual environment. ODBC Driver 18 for SQL Server must be installed on the host.

  3. Store the password outside the repo. Put it in a plain-text file somewhere the repo can't reach (not under the project folder):

    # Windows PowerShell, UTF-8, password only, no quotes/newline
New-Item -ItemType Directory -Force C:\Users\you\secrets | Out-Null
Set-Content -NoNewline -Encoding utf8 C:\Users\you\secrets\mcp_sql.pwd 'your-password'

    Or skip the password entirely with integrated auth (MCP_SQL_TRUSTED=yes) — preferred for CJIS/PCI. See Secret handling below for all options.

  4. Configure your MCP client. Copy the sql-querystore block from claude_desktop_config.example.json into your real Claude Desktop config (Windows: %APPDATA%\Claude\claude_desktop_config.json), then replace the placeholder paths, server name, and MCP_SQL_PWD_FILE. Set MCP_SQL_TRUST_CERT=yes only for a self-signed/local cert; leave it no against instances with proper certificates.

  5. Restart your MCP client and confirm the server shows as running.

Never commit your real config or your password file. .gitignore already excludes *.pwd, .env, and claude_desktop_config.json.

Related MCP server: mssql-health-mcp

Security model (read this first)

The read-only guarantee comes from the SQL login's permissions, not from any code in this repo:

  • Provision a dedicated login with VIEW DATABASE STATE (and VIEW SERVER STATE only if you use server-scoped DMVs) and nothing else — no db_datareader, no SELECT on user tables. See provisioning/create_readonly_login.sql.

  • The keyword screen in db.py and the fixed SELECT-only query text are defense-in-depth, not the primary control.

  • ApplicationIntent=ReadOnly in the connection string only routes to a readable secondary in an availability group. On a standalone instance it does not make the session read-only. Do not rely on it for safety.

  • Credentials never belong in code. The simplest setup uses the MCP_SQL_CONNECTION_STRING env var, but for CJIS/PCI environments prefer integrated auth or a file/secret-store-sourced password — see the Secret handling section below.

  • Every query is recorded via the audit logger — see Audit logging below. In a regulated environment, route that logger to a durable file or SIEM.

Setup

ODBC Driver 18 for SQL Server must be installed on the host. Install the package, then configure the connection via environment variables (see Secret handling for all options). The recommended form keeps the password in a file, not inline:

pip install -e .

# PowerShell — connection assembled from parts, password read from a file
$env:MCP_SQL_SERVER      = "yourhost\INSTANCE"
$env:MCP_SQL_DATABASE    = "master"
$env:MCP_SQL_UID         = "mcp_readonly"
$env:MCP_SQL_PWD_FILE    = "C:\path\to\your\secret.pwd"
$env:MCP_SQL_TRUST_CERT  = "no"   # "yes" only for a self-signed/local cert

python -m mcp_sql_querystore.server

Or use integrated auth with no stored password at all (MCP_SQL_TRUSTED=yes). A full MCP_SQL_CONNECTION_STRING is also accepted for simple cases — see Secret handling.

Register it with your MCP client (e.g. Claude Desktop) as an stdio server invoking python -m mcp_sql_querystore.server; see claude_desktop_config.example.json.

Tools

All tools are read-only and take a database_name (except sweep_regressions, which can sweep all databases). Each returns JSON, or a structured error dict on failure rather than raising.

  • get_regressed_queries — compares a recent window against an earlier baseline window per query and flags those worse by at least regression_threshold. A real baseline-vs-recent comparison, not a top-CPU list.

  • get_query_execution_plan — returns compiled plans for a query_id with a compact JSON summary (missing indexes, warnings incl. implicit conversions, key lookups) and optional raw XML.

  • analyze_parameter_sniffing — finds queries with multiple compiled plans and ranks them by the ratio of slowest to fastest plan mean duration — the classic parameter-sniffing signature.

  • get_missing_index_impact — scans recent plans containing missing-index recommendations, parses the impact score from the plan XML, and aggregates duplicate recommendations across queries, ranked by impact then recurrence.

  • get_wait_stats — aggregates query wait time by wait category over a window, showing why queries are slow (CPU, blocking/locks, IO, memory) rather than which. De-duplicates flushed vs in-memory rows per Microsoft guidance.

  • sweep_regressions — runs regression detection across all Query Store-enabled online databases (or an explicit database_names list) and returns the worst per database, ranked. One failing database does not abort the sweep; its error is collected and reported.

Example prompts

Once the server is connected to your MCP client, you drive the tools in plain language. Name the target database in the prompt (except sweep_regressions, which can scan all of them). Replace YourDB with your database name.

Wait stats — why queries are slow

  • "What are the top wait categories in YourDB over the last week?"

  • "Is YourDB waiting on CPU, memory, or IO?"

  • "Show me wait stats for YourDB over the last 24 hours."

Execution plans

  • "Get the execution plan for query_id 10 in YourDB and summarize it."

  • "Does query_id 13 in YourDB have missing index recommendations?"

  • "Are there implicit conversion warnings in query 12's plan in YourDB?"

Regression analysis

  • "Check YourDB for CPU regressions over the last 24 hours."

  • "Which queries in YourDB regressed by more than 30%?"

  • "Find duration regressions in YourDB, ignoring anything with fewer than 10 executions."

Parameter sniffing

  • "Check YourDB for parameter sniffing."

  • "Which queries in YourDB have unstable plans?"

Missing indexes

  • "What missing indexes does YourDB need most?"

  • "Show me the top 10 index recommendations for YourDB by impact."

Multi-database sweep (no database name needed)

  • "Sweep all my databases for CPU regressions."

  • "Which database has the worst regressions this week?"

Combined — chaining tools in one turn

  • "Find the biggest CPU regression in YourDB, pull its plan, and tell me why it might have regressed."

  • "YourDB feels slow — diagnose it." (wait stats → regressions → plans)

  • "Full performance triage of YourDB: wait stats, top regressions, and missing indexes."

Known caveats / TODO

  • Version differences. Query Store column names assume SQL Server 2019+/2022 and Azure SQL MI. Verify against 2016/2017 if you target those.

  • Regression semantics. Current logic uses execution-weighted averages. You may prefer percentile-based comparison (Query Store doesn't store percentiles directly, so that needs *_stdev columns and assumptions).

  • Not time-windowed: analyze_parameter_sniffing aggregates across all Query Store history; on busy databases consider adding a recent_hours filter like the other tools have.

  • Remaining hardening: connection retry with backoff, and version-aware column handling for mixed 2016/2017/2019/2022 fleets.

Secret handling

The connection string is resolved in this order, so the password need not sit in plaintext config:

  1. MCP_SQL_CONNECTION_STRING — the full string (simplest; back-compat).

  2. MCP_SQL_CONNECTION_STRING_FILE — path to a file holding the full string (Docker/K8s secret-mount style).

  3. Assembled from parts: MCP_SQL_SERVER (+ MCP_SQL_DATABASE, MCP_SQL_DRIVER, MCP_SQL_ENCRYPT, MCP_SQL_TRUST_CERT, MCP_SQL_EXTRA). Auth is either:

    • Integrated (preferred for CJIS/PCI — no password stored): MCP_SQL_TRUSTED=yes.

    • SQL auth: MCP_SQL_UID plus the password from MCP_SQL_PWD_FILE (a vault-mounted file), MCP_SQL_PWD_ENV (name of another env var), or MCP_SQL_PWD (direct; least preferred).

Timeouts: MCP_SQL_CONNECT_TIMEOUT (default 10s) and MCP_SQL_QUERY_TIMEOUT (default 30s, 0 disables).

Audit logging

Every query attempt is logged via the mcp_sql_querystore.audit logger: tool, database, a 12-char hash of the SQL (not the text), row count, elapsed ms, and outcome. Connection strings, SQL text, and parameter values are never logged. Configure a handler for that logger to route the audit trail to a file or SIEM.

Testing

Unit tests (no database, safe in CI):

pip install -e ".[test]"
pytest

Integration tests (real instance, opt-in):

# set a working connection (any form above), then:
$env:MCP_SQL_TEST_DATABASE = "RAG"
$env:MCP_SQL_RUN_INTEGRATION = "1"
pytest tests/test_integration.py -v

Available Tools

6 tools
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.

ParametersJSON Schema
NameRequiredDescriptionDefault
top_nNoMax rows to return.
database_nameYesTarget SQL Server database name.
min_plan_countNoMinimum distinct plans for a query to be considered (2 = at least two plans).

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the ranking mechanism (slowest-to-fastest plan mean duration ratio) and implicitly that this is a read/analysis operation, but says nothing about permissions, whether it is read-only, cost, or result shape.

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 tight sentences, front-loaded with the detection target followed by the ranking rule. No filler.

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?

With no output schema and no annotations, the description partially compensates by describing the ranking metric. However, it omits usage context, read-only status, and any sense of output columns, leaving meaningful gaps for a diagnostic 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 description coverage is 100%, so database_name, top_n, and min_plan_count are already documented in the schema. The description adds no parameter syntax or defaults beyond what the schema states; baseline 3 applies.

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

Purpose4/5

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

States a specific verb+resource: detecting queries whose runtime varies across compiled plans, and names the phenomenon (parameter sniffing). It also gives the ranking criterion. It does not explicitly differentiate itself from get_regressed_queries or sweep_regressions, which is the only gap.

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

Usage Guidelines2/5

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

No guidance on when to reach for this tool vs. get_regressed_queries, sweep_regressions, or get_query_execution_plan. The description implies a diagnostic context but never states prerequisites or exclusions.

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

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
top_nNoMax index recommendations to return.
database_nameYesTarget SQL Server database name.
plan_scan_limitNoHow many recent plans (that contain missing indexes) to scan and aggregate. Higher = more thorough, slower.

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose non-obvious behavior: it scans Query Store plans, ranks by the optimizer's estimate, and deduplicates recommendations across queries. However, it omits read-only confirmation, the cost/latency implication of plan_scan_limit (only hinted in the schema), and any note about what the impact score does or does not account for.

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 compact sentences, front-loaded with what is aggregated and how it is ranked, then the deduplication behavior. No filler.

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 no output schema, the description must convey the return shape, and it does so reasonably (aggregated, ranked recommendations). The main remaining gap is the absence of any cost or scope caveat for a tool that scans hundreds of plans by default.

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 top_n, database_name, and plan_scan_limit are already fully documented, including the plan_scan_limit thoroughness/speed tradeoff. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb (aggregate) and resource (missing-index recommendations from Query Store plans), plus the ordering criterion (optimizer's estimated impact score). The resource is unique enough among the siblings (regressed queries, execution plans, wait stats) that an agent can tell it apart, though it never names a sibling explicitly.

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?

Usage is implied — an agent would call this to decide which missing indexes to add — but there is no explicit statement of when to prefer it over get_query_execution_plan or the other siblings, and no exclusions or prerequisites.

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

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
query_idYesQuery Store Query ID.
include_xmlNoInclude raw showplan XML alongside summary.
database_nameYesTarget SQL Server database name.

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It implies a read-only fetch and discloses the return shape (compact summary plus optional raw XML), which is useful. However, it omits permission requirements, the cost/latency of pulling showplan XML, and whether multiple plans may be returned (the '(s)' hints at it but never resolves).

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?

A single front-loaded sentence that states the operation, the input scope, and the return payload with zero filler. Nothing could be removed without losing information.

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 no output schema and no annotations, the description does a fair job of specifying what is returned (missing indexes, warnings, lookups, optional XML). It lacks operational caveats -- permissions, Query Store availability, and the multi-plan ambiguity from '(s)' -- but is otherwise sufficient for a read-only introspection 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 description coverage is 100%, so all three parameters are already documented in the schema. The description adds only marginal meaning -- 'optional raw XML' maps to include_xml defaulting to false, and query_id is referenced as Query Store-specific. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

Names a specific verb (Fetch) and resource (execution plan(s)) scoped to a Query Store query_id, and states what comes back (missing indexes, warnings, lookups, optional XML). It is clearly distinguishable from siblings like get_wait_stats or analyze_parameter_sniffing, though it never explicitly contrasts itself with them -- notably get_missing_index_impact, which overlaps on missing-index output.

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

Usage Guidelines2/5

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

The description gives no when-to-use guidance, no prerequisites (e.g. Query Store must be enabled, database must be online), and no routing advice against the overlapping get_missing_index_impact sibling. Usage is only implied by the query_id parameter.

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

get_regressed_queriesB

Detect queries whose performance regressed by comparing a recent period against an earlier baseline period from Query Store.

ParametersJSON Schema
NameRequiredDescriptionDefault
top_nNoMax rows to return.
metricNoMetric to evaluate regression against.cpu_time
recent_hoursNoLength of the recent window, in hours.
database_nameYesTarget SQL Server database name.
baseline_hoursNoLength of the baseline window preceding the recent window, in hours (default 7 days).
min_executionsNoIgnore queries with fewer executions than this in either period (filters noise).
regression_thresholdNoMinimum fractional worsening to flag (0.5 = 50% worse than baseline).

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden, and it does disclose the core behavior: a comparison of a recent window against a preceding baseline. It omits whether the operation is read-only, the cost of querying Query Store, permission requirements, and whether results include the regressed query text or plan.

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?

A single front-loaded sentence that names the action, the subject, and the comparison mechanism with zero filler. Nothing is padded or repeated from the schema.

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?

For a 7-parameter analytical tool with no annotations and no output schema, the description covers the 'what' but leaves the return shape, ordering, and the boundary against sweep_regressions unstated. Adequate but with clear gaps an agent would have to guess around.

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 every parameter (top_n, metric, recent_hours, baseline_hours, min_executions, regression_threshold) is already documented in the schema with defaults and semantics. The description adds the conceptual framing of 'recent vs. baseline' but no syntax or edge-case detail beyond the schema.

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

Purpose4/5

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

States a specific verb+resource ('Detect queries whose performance regressed') and the mechanism (recent period vs. earlier baseline from Query Store), so the agent knows exactly what it returns. It does not, however, distinguish itself from the sibling sweep_regressions, which by name appears to overlap heavily with this capability.

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?

There is no guidance on when to choose this over sweep_regressions, get_query_execution_plan, or get_wait_stats, nor any prerequisite (e.g. Query Store must be enabled). Usage must be inferred entirely from the one-sentence purpose.

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

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
top_nNoMax wait categories to return.
recent_hoursNoLookback window in hours.
database_nameYesTarget SQL Server database name.

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It is transparent about what it aggregates, the time window, and the ranking order, but never states that it is a read-only operation, what permissions are required, or what the returned units/columns look like, with no output schema to fall back on.

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?

A single front-loaded sentence with an em-dash clarification; the core action comes first and the diagnostic value proposition follows. No filler sentences.

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 no-output-schema diagnostic read tool, the description conveys what is returned (wait time aggregated by category, ranked by total wait time), which is enough to call it correctly. Minor gaps remain around result units and whether wait times are per-category totals or averages.

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%: all three parameters (top_n, recent_hours, database_name) are documented inline with defaults. The description reinforces the idea of a time window and category grouping but adds no syntax, units, or bounds beyond the schema, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Aggregate query wait time by wait category over a time window') and adds a genuine differentiator: it exposes WHY queries are slow rather than WHICH are slow, which separates it in kind from query-level siblings. It does not name a specific sibling, so it falls short of a 5.

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?

Usage is implied by the 'WHY vs which' framing — an agent can infer this is a diagnostic tool for root-causing slowness rather than finding slow queries. However, no explicit when-to-use condition, prerequisite, or named alternative (e.g. get_regressed_queries, get_query_execution_plan) is given.

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

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
metricNoMetric to evaluate regression against.cpu_time
recent_hoursNoLength of the recent window, in hours.
top_n_per_dbNoMax regressed queries to return per database.
baseline_hoursNoLength of the baseline window, in hours.
database_namesNoOptional explicit list of databases to sweep. If omitted, sweeps all Query Store-enabled online databases.
min_executionsNoIgnore queries below this execution count.
regression_thresholdNoMinimum fractional worsening to flag.

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It does reveal the automatic filtering behavior (only online, Query Store-enabled databases) and the per-database aggregation of results, but says nothing about permission requirements, runtime cost of sweeping an entire instance, or whether the operation is strictly read-only. Adequate but with real gaps for an instance-wide sweep.

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 filler, and the scope (ALL Query Store-enabled databases) is front-loaded ahead of the usage hint. Every clause earns its place.

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?

With no output schema and no annotations, the description should shoulder more of the load. It only gestures at the return value ('worst regressions found per database') without describing the fields or shape, and omits any caveats about instance-wide cost or permissions, leaving an agent able to call it but uncertain about results.

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 all seven parameters (metric, windows, thresholds, top_n_per_db, database_names) are already documented in the schema. The description adds no syntax, defaults, or semantics beyond what the schema states, so the baseline 3 applies.

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

Purpose5/5

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

The description gives a specific verb (run regression detection), an explicit scope (ALL online databases with Query Store enabled), and the return shape (worst regressions per database). The phrase 'instead of one database at a time' cleanly separates it from single-database siblings like get_regressed_queries.

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?

'Use this to triage a whole instance instead of one database at a time' states when to reach for this tool versus the per-database alternative. It stops short of explicit exclusions (e.g., when NOT to sweep, or cost concerns on large instances), so it is clear context without full when/when-not guidance.

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. 6 tool updatesv0.1.0
    • First observedanalyze_parameter_sniffing
    • First observedget_missing_index_impact
    • First observedget_query_execution_plan
    • First observedget_regressed_queries
    • First observedget_wait_stats
    • First observedsweep_regressions
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 6 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Microsoft SQL Server MCP

    NicolasPirello
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to connect and query Microsoft SQL Server databases using natural language, executing read-only SQL queries for safe data inspection and analysis.
    MIT

  • mssql-health-mcp

    dmcteknoloji
    A
    license
    A
    quality
    D
    maintenance
    Provides read-only SQL Server health and diagnostic tools using DMVs, enabling users to query server health, active queries with blocking, and missing indexes through natural language.
    3
    1
    MIT

  • sqlserver-mcp

    moigomes
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables secure interaction with Microsoft SQL Server databases, allowing schema exploration, metadata retrieval, and read-only query execution through natural language.
    1
    -