[FEATURE] Feature Request: Configurable query timeout for MCP tool calls

[gdonufrio]

Which component(s) does this affect?

• Full Dashboard
• Lite
• SQL collection scripts
• Installer
• Documentation

Problem Statement

Hi there,
First of all, thank you so much for this incredible tool — it's been a game-changer for SQL Server monitoring and troubleshooting. The MCP integration with Claude Code is brilliant and has saved us countless hours.
A friend of mine who uses the Performance Monitor Dashboard extensively via MCP has been running into timeout issues when querying larger databases. For example, tools like get_query_store_top or get_top_queries_by_cpu tend to time out on databases with very large plan caches or Query Store catalogs (think 400M+ rows in stats tables, 600GB+ databases).

Proposed Solution

The request: would it be possible to add a configurable query timeout setting — either in the MCP server
configuration, in the app settings, or as an optional parameter on the MCP tools themselves?

▎ Something like:
▎ - A global setting (e.g., mcp_query_timeout_seconds: 120) in a config file
▎ - Or an optional @timeout parameter on individual tool calls
▎ - Or even a per-server timeout override

Currently the timeout seems to be a fixed default (~30-60 seconds), and for heavier databases there's no way to increase it without modifying the source. Having a user-configurable option would make the tool much more usable on larger production environments.

Use Case

Use case: we monitor a production SQL Server 2017 Standard with multiple databases, the largest being ~600GB with 100M+ rows in the states tables and a very active Query Store. When using Claude Code with the MCP integration, tools like get_query_store_top and get_top_queries_by_cpu consistently time out on this database. The smaller databases on the same server work fine. We end up having to run the queries manually in SSMS and paste the results back to Claude, which defeats the purpose of the MCP integration.

For context, during a recent optimization project we relied heavily on the MCP tools for iterative analysis (wait
stats trending, procedure stats comparison, plan XML retrieval). Everything worked great except for the Query Store
queries on the large database — those always timed out, forcing us to fall back to manual queries.

Alternatives Considered

Alternatives considered:

• Running the queries manually in SSMS and pasting results back to Claude — works but loses the interactive workflow that makes MCP so powerful
• Reducing hours_back and top parameters to minimize query scope — helps sometimes but still times out on the larger databases
• Splitting the analysis across multiple smaller calls — adds friction and doesn't always work when the underlying
  query itself is heavy (e.g., Query Store aggregation on 100M+ runtime stats rows)

Additional Context

Thank you again for all the amazing work on this project.
We really appreciate it!

Best regards

[erikdarlingdata]

@gdonufrio What version are you running? I used to run into this on older schema before I added compression to the big columns, and reworked the queries.

[erikdarlingdata]

Fixed in PR #830. The three MCP tools now use multi-phase queries that aggregate numerics first, rank TOP N, then hydrate text only for the winners:

• Dashboard: Temp table phases — DECOMPRESS runs on ~N rows instead of the entire table
• Lite: CTE-based phasing with LEFT JOIN LATERAL for text hydration
• Both: database_name filter pushed into SQL, no more client-side filtering

Server-side execution times are all under 100ms on test data. The 120s timeout should now be more than sufficient even for very large databases.

[erikdarlingdata]

Before vs After: Server-Side Execution Times (SQL2022)

Before — single-pass queries with DECOMPRESS on every row, no TOP pushdown, client-side filtering:

Tool	Behavior
get_top_queries_by_cpu	Full table scan + DECOMPRESS in WHERE on every row, return all results, filter client-side
get_query_store_top	Full table scan + DECOMPRESS in WHERE on every row, return all results, filter client-side
get_top_procedures_by_cpu	Full table scan + DECOMPRESS plan XML on every row, return all results, filter client-side

On 600GB+ databases with 100M+ rows, these consistently exceeded the 120s timeout.

After — multi-phase: aggregate numerics → rank TOP N → hydrate text for winners only:

Tool	Avg Elapsed	CPU	Logical Reads
get_top_queries_by_cpu	87ms	277ms	112,162
get_top_queries_by_cpu (w/ db filter)	38ms	113ms	46,314
get_query_store_top	10ms	20ms	15,936
get_query_store_top (w/ db filter)	8ms	8ms	7,926
get_top_procedures_by_cpu	7ms	7ms	610

DECOMPRESS now runs on ~25 rows instead of the entire table.

[gdonufrio]

I use Always the latest version

[gdonufrio]

Thank you so much