@deepsql/mcp 0.21.0 → 0.23.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,31 +0,0 @@
1
- ---
2
- name: slow-query-optimize
3
- description: Diagnose why a query is slow and propose a rewrite, using DeepSQL's plan analysis and AI query optimizer.
4
- version: 1.0.0
5
- platforms: [linux, macos, windows]
6
- metadata:
7
- hermes:
8
- tags: [slow, query, optimize, explain, plan, performance, rewrite, regression, deepsql]
9
- related_skills: [index-advisor, workload-analysis]
10
- ---
11
-
12
- # Slow Query Optimize
13
-
14
- Use when the user points at a specific query and asks "why is this slow?" or "make this faster." For workload-level "what's slow overall?" use `workload-analysis` instead.
15
-
16
- ## Procedure
17
-
18
- 1. **Resolve the connection** (`list_connections` → UUID).
19
-
20
- 2. **Analyze the plan.** `analyze_query_plan(connectionId, sql)` returns the parsed plan tree, performance issues, missing-index hints, and a written summary that already accounts for the connection's schema and business rules. Use `useAnalyze: false` by default — `useAnalyze: true` actually executes the query (and for a mutation, triggers the same admin + confirm gate as `execute_sql`).
21
-
22
- 3. **Get an AI rewrite** for a specific statement with `optimize_slow_query(connectionId, sql, avgExecutionTimeMs=…)`. Pass the average execution time to anchor the impact estimate. Note: this is single-query scoped and does NOT recommend indexes — route index questions to the `index-advisor` skill.
23
-
24
- 4. **If the query came from the live workload**, identify it by fingerprint first: `analyze_slow_queries` (recent slow queries with fingerprints) → `get_query_samples(fingerprint)` for a real statement with bind values to plan against → `get_slow_query_timeline(queryId)` to confirm whether it's actually getting slower.
25
-
26
- 5. **Report:** the root cause (slow node, bad estimate, missing index, plan drift), the proposed rewrite, and the expected improvement. If the real fix is an index, say so and hand off to `index-advisor`.
27
-
28
- ## Guardrails
29
-
30
- - Don't run a mutation just to time it. `useAnalyze: true` on an `UPDATE`/`DELETE` executes it — only do that with admin role and explicit confirmation.
31
- - A rewrite that changes result semantics is a bug, not an optimization. Preserve the business rules (filters, soft-deletes) the original query respected.
@@ -1,36 +0,0 @@
1
- ---
2
- name: workload-analysis
3
- description: Explain what's driving database load — slow-query hotspots, regressions, per-customer load, and table growth — across the whole workload.
4
- version: 1.0.0
5
- platforms: [linux, macos, windows]
6
- metadata:
7
- hermes:
8
- tags: [workload, slow-queries, regression, hotspots, growth, anomaly, customers, deepsql]
9
- related_skills: [slow-query-optimize, index-advisor]
10
- ---
11
-
12
- # Workload Analysis
13
-
14
- Use for whole-workload questions: "what's slow right now?", "what regressed this week?", "which customer is driving load?", "what's growing fast?" For a single named query, use `slow-query-optimize`.
15
-
16
- ## Procedure
17
-
18
- 1. **Resolve the connection** (`list_connections` → UUID).
19
-
20
- 2. **Find the hotspots.** `get_slow_query_insights(connectionId, kind="all", window=…)` returns pre-computed AI insights grouped as `hotspots` (most total DB time), `remediation` (actionable fixes), `tail-risk` (p95/max outliers), `plan-drift` (plan changed), `skew` (one tenant overloaded). `analyze_slow_queries` and `list_tracked_queries` give the raw fingerprint list with call counts and mean/max times.
21
-
22
- 3. **Catch regressions.** `get_query_regressions(connectionId)` ranks queries that got slower on the latest analysis run by slowdown factor. Drill into one with `get_slow_query_timeline(queryId)` to see the day-by-day trend.
23
-
24
- 4. **Attribute load.** `get_slow_query_customers(connectionId)` ranks tenants/customers by total slow-query time (with resolved customer name when configured) — answers "who is driving the load?"
25
-
26
- 5. **Watch growth.** `get_table_growth(connectionId)` for size/row-count trends; `get_growth_anomalies(connectionId)` for tables growing abnormally. These predict the next performance cliff before it hits.
27
-
28
- 6. **Synthesize, then route.** Lead with the few things that matter most (biggest total-time consumer, worst regression, fastest-growing table). For each, hand off to the right next step: a specific slow query → `slow-query-optimize`; an indexing opportunity → `index-advisor`.
29
-
30
- ## Guardrails
31
-
32
- - Rank by **total** impact (`calls × mean_exec_time`), not by single-execution worst case — a 5-second query run twice a day matters less than a 200ms query run a million times.
33
- - Start with compact persisted analytics (`get_latest_slow_query_analysis`, `get_slow_query_insights`, `list_tracked_queries`). If a persisted payload is too large/truncated to inspect cleanly, pivot to the compact endpoints rather than trying to parse the oversized blob.
34
- - Use `analyze_slow_queries` when you need a fresh top-N snapshot for the last 24 hours; say explicitly that this triggers fresh analysis work, unlike the persisted analytics endpoints.
35
- - Everything here is read-only and analytics-store backed unless you intentionally call `analyze_slow_queries` for a fresh collection. Say so if the user worries about adding load.
36
- - `get_query_samples` exposes literal bind values — treat the output as potentially sensitive data.
@@ -1,46 +0,0 @@
1
- # DeepSQL Agent — terminal skin (subtle mono grey). Rebrands the Hermes TUI/CLI.
2
- # Ships in the profile distribution under <profile>/skins/, activated via
3
- # `display.skin: deepsql` in the profile's config.yaml. The DeepSQL wordmark +
4
- # tagline live in the (vendored) TUI source (banner.ts / branding.tsx); this skin
5
- # drives colors + branding strings.
6
- name: deepsql
7
- description: DeepSQL Agent — subtle mono
8
-
9
- colors:
10
- # Prominent elements (wordmark, "What I can do" header, category labels, ✨ Try)
11
- # use a mid-tone MAROON/garnet — a saturated mid-luminance color contrasts with
12
- # BOTH light and dark terminal backgrounds (pure greys vanish on one of them).
13
- # Body text is a warm neutral. Wordmark gradient = primary→accent→border.
14
- banner_border: "#8E3B4A" # deep maroon — wordmark bottom rows + panel border
15
- banner_title: "#B14A5C" # garnet — wordmark top rows + the section header
16
- banner_accent: "#8E3B4A"
17
- banner_dim: "#A89BA0" # warm mid-grey — prompts / metadata (readable on both)
18
- banner_text: "#D2C7CB" # warm light-grey — descriptions
19
- ui_accent: "#CC6B7D" # rose-maroon — wordmark mid rows + labels + ✨ Try
20
- ui_label: "#CC6B7D"
21
- ui_ok: "#3FA796"
22
- ui_error: "#E5484D"
23
- ui_warn: "#E6B15C"
24
- prompt: "#DDD4D7"
25
- input_rule: "#5A4348"
26
- response_border: "#5A4348"
27
- status_bar_bg: "#1A1113"
28
- status_bar_text: "#D2C7CB"
29
- status_bar_strong: "#E8DDE0"
30
- status_bar_dim: "#A89BA0"
31
- status_bar_good: "#3FA796"
32
- status_bar_warn: "#E6B15C"
33
- status_bar_bad: "#E5484D"
34
- status_bar_critical: "#E5484D"
35
- session_label: "#A89BA0"
36
- session_border: "#8E3B4A"
37
-
38
- branding:
39
- agent_name: "DeepSQL Agent"
40
- welcome: "DeepSQL Agent — ask about your database, or /help for commands."
41
- goodbye: "Bye."
42
- response_label: " DeepSQL "
43
- prompt_symbol: "❯"
44
- help_header: "Commands"
45
-
46
- tool_prefix: "│"
@@ -1 +0,0 @@
1
- 0.17.0