Problem
8 DuckDB tables have collected data but no MCP tool to expose it. The most critical gap is query_snapshots — when the analysis engine detects a CPU spike, there's no MCP tool to answer "what query was running at that time?"
Missing Tools
| Priority |
Table |
What it contains |
Suggested tool |
| High |
query_snapshots |
Active queries from sp_WhoIsActive |
get_active_queries (with time window filter) |
| High |
server_config |
sp_configure key/value pairs |
get_server_config |
| High |
database_config |
RCSI, recovery model, auto-shrink, etc. |
get_database_config |
| Medium |
database_size_stats |
Database/file sizes, volume free space |
get_database_sizes |
| Medium |
server_properties |
Edition, version, CPU count, memory |
get_server_info |
| Medium |
session_stats |
Connection counts, running/sleeping |
get_session_stats |
| Low |
trace_flags |
Active trace flags |
get_trace_flags |
| Low |
database_scoped_config |
Database-scoped config values |
get_database_scoped_config |
database_scoped_config is also not read by the analysis engine — complete blind spot.
Context
Found during ErikAI testing: analyze_server detected a CPU spike to 99% and recommended get_top_queries_by_cpu, but that tool shows plan cache aggregates, not point-in-time snapshots. The actual query causing the spike was only findable by querying query_snapshots directly via Python.
Acceptance Criteria
- Each table above has a dedicated MCP tool returning its data
- Tools support
server_name and hours_back parameters
get_active_queries supports time window filtering (start/end or hours_back)
Problem
8 DuckDB tables have collected data but no MCP tool to expose it. The most critical gap is
query_snapshots— when the analysis engine detects a CPU spike, there's no MCP tool to answer "what query was running at that time?"Missing Tools
query_snapshotsget_active_queries(with time window filter)server_configget_server_configdatabase_configget_database_configdatabase_size_statsget_database_sizesserver_propertiesget_server_infosession_statsget_session_statstrace_flagsget_trace_flagsdatabase_scoped_configget_database_scoped_configdatabase_scoped_configis also not read by the analysis engine — complete blind spot.Context
Found during ErikAI testing:
analyze_serverdetected a CPU spike to 99% and recommendedget_top_queries_by_cpu, but that tool shows plan cache aggregates, not point-in-time snapshots. The actual query causing the spike was only findable by queryingquery_snapshotsdirectly via Python.Acceptance Criteria
server_nameandhours_backparametersget_active_queriessupports time window filtering (start/end or hours_back)