SQL Server monitoring and diagnostics for AI agents using Extended Events
SQL Sentinel provides 15 tools with reasonable coverage of SQL Server diagnostics and profiling. Tool naming follows the verb_noun convention consistently (list_tables, describe_table, get_deadlocks, etc.), which is good. Descriptions are present for all tools and most are substantive (100-300 chars), meeting baseline expectations. However, several critical quality gaps emerge: (1) Input schemas are incomplete, many tools have minimal or no parameter descriptions despite visible parameters in the function signatures; (2) Output schemas are not documented, there is no indication of what fields the response objects contain, making it difficult for LLMs to reason about downstream usage; (3) Error handling guidance is absent, tools return JsonSerializer.Serialize(DbOperationResult) but the shape and content of error responses is never described to the LLM; (4) Parameter validation rules are not explicitly stated (e.g., what constitutes a valid 'sessionName', format constraints for 'captureId', acceptable ranges for 'topN', 'limit', 'offset'); (5) Security-sensitive tools like sqlsentinel_grant_permissions lack prominent warnings about privilege requirements and side effects. Tool descriptions are reasonably detailed and context-aware (e.g., sqlsentinel_get_blocking explains the 'blocked process threshold' prerequisite), but parameter-level documentation is sparse.
Check if the current SQL Server login has the required permissions for profiling. Required permissions for SQL Sentinel: - ALTER ANY EVENT SESSION: Create, modify, and drop Extended Events sessions - VIEW SERVER STATE: Read from ring buffer targets and DMVs Returns the current permission status and provides GRANT statements if permissions are missing.
Returns detailed schema information for a table including columns, indexes, constraints, and foreign keys.
Retrieve blocked process events captured by a profiling session. PREREQUISITE: 'blocked process threshold' must be configured on the server: EXEC sp_configure 'blocked process threshold', 5; -- triggers after 5 seconds RECONFIGURE; Sessions must include the BlockedProcess event type. Returns blocked and blocking SPID pairs with wait resources and SQL text.
Retrieve deadlock events captured by a profiling session. Sessions must include the Deadlock event type (maps to sqlserver.xml_deadlock_report). Returns structured deadlock information: victim process, all involved SPIDs, wait resources, lock modes, and SQL text per process.
Retrieve captured events from a profiling session with filtering. Returns query events with timing, resource usage, and metadata. Supports filtering by time, database, application, duration, and text content. When deduplicate=true (default), identical queries are grouped with execution counts.
Output schemas not documented. Tools return structured responses (e.g., DbOperationResult, profiling summaries, capture details) but there is no documentation of the response field names, types, or structure. LLMs cannot reason about what data is available or how to chain tool calls without explicit response schema documentation.
Parameter descriptions are minimal or missing. While tool descriptions are substantive, individual parameter annotations lack detail. For example, 'sessionName' is described only as 'Name of the profiling session', it does not explain valid formats, whether it must exist, or how to discover valid session names. Parameters like 'responseFormat' default to 'Markdown' but lack enum declarations or explanation of available options.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Get aggregate statistics from captured events. Provides summary metrics grouped by query fingerprint, database, application, or login. Useful for identifying slow queries, high-frequency queries, or resource-intensive operations.
Query sys.dm_os_wait_stats to show what SQL Server is waiting on. This does NOT require a profiling session - it queries the server directly. Shows cumulative wait statistics since the last SQL Server restart or manual reset. Useful for identifying systemic bottlenecks. Waits are categorized as: CPU, I/O, Lock, Memory, Network, Latch, Preemptive, Other. Common benign waits (SLEEP_*, BROKER_*, background tasks) are excluded.
Grant the required profiling permissions to a specified SQL Server login. IMPORTANT: The connection used must have elevated privileges (sysadmin role or CONTROL SERVER permission). Grants: - ALTER ANY EVENT SESSION: Create, modify, and drop Extended Events sessions - VIEW SERVER STATE: Read from ring buffer targets and DMVs
Single diagnostic command that produces a comprehensive server health report. Pulls together: - Top 5 slowest queries (requires an active profiling session) - Recent deadlocks (if session includes Deadlock event type) - Recent blocking events (if session includes BlockedProcess event type) - Top 10 wait statistics from sys.dm_os_wait_stats - Currently active blocking chains from sys.dm_exec_requests - AI-ready insights with severity and recommendations For sessionName: pass an active or stopped session to include query/event analysis. Pass empty string to skip query analysis and only return live DMV data.
Lists all user tables in the SQL Server database. Returns schema-qualified table names (e.g., 'dbo.Users').
Get full details of a specific past capture by its ID. Returns the complete capture summary including top queries by duration, insights, diagnostic findings, and context from that profiling session. Use capture IDs from sqlsentinel_memory_list.
List past profiling captures stored in memory. Returns summaries of previous profiling sessions that were automatically saved when you retrieved events, stats, or ran health checks. Use this to discover what data is available from past operations without re-running them. Memory persists across server restarts and conversation compaction. Filter by server name, session name, tag, or time range.
Get the performance history of a specific query fingerprint across all captures. Shows how a query's performance has changed over time: execution counts, average/max duration, reads, and CPU usage across multiple profiling sessions. Use this to detect performance regressions or improvements. Get query fingerprints from get_events, get_stats, or memory_search_queries.
Search through remembered queries across all past captures. Find queries by SQL text content, database, minimum execution count, or minimum average duration. Returns query fingerprints with their cumulative statistics and performance history. Results are sorted by total duration (heaviest queries first).
Add tags or a note to a past capture for easier retrieval later. Tags help categorize captures (e.g., 'before_deploy', 'regression_test', 'production_issue'). Notes provide free-form context about what the capture was for. Tagged captures have extended retention (90 days vs 30 days default).
No error handling or recovery guidance. Tool descriptions do not explain what errors might occur, how to detect them, or what to do next. For example, if a profiling session does not exist, should the LLM create one? List available sessions? Return empty results? The tool description is silent, forcing the LLM to guess or fail silently.
Parameter constraints not declared. Numeric parameters like 'topN', 'limit', 'offset', 'slowQueryThresholdMs', 'minDurationMs' lack minimum/maximum bounds in descriptions. The 'limit' parameter in sqlsentinel_get_events shows a constraint (1-10000) in the schema annotation but not in the description text, LLMs rely on description text, not JSON Schema, for constraints.
Destructive tool lacks confirmation pattern. sqlsentinel_memory_tag allows tagging captures but sqlsentinel_grant_permissions modifies server permissions with high impact (grants ALTER ANY EVENT SESSION globally). The tool description notes 'IMPORTANT: The connection used must have elevated privileges' but there is no dry-run, confirmation, or simulation mode to prevent accidental permission escalation.
Enum parameters not explicitly declared. 'responseFormat' (Json or Markdown), 'sortBy' (TimestampAsc, TimestampDesc, DurationAsc, DurationDesc, CpuDesc, ReadsDesc), and 'groupBy' (QueryFingerprint, Database, Application, Login, None) accept a fixed set of values but are not declared as enums in descriptions. LLMs may hallucinate invalid values.
No permission scope declarations. Tools like sqlsentinel_grant_permissions, sqlsentinel_check_permissions, and sqlsentinel_list_tables do not declare what permissions they require (e.g., 'read:diagnostics', 'write:permissions'). This prevents least-privilege agent configuration and makes audit trails ambiguous.