@deepsql/mcp 0.22.0 → 0.26.0

package/agent-profile/skills/index-advisor/SKILL.md

@@ -1,34 +0,0 @@
----
-name: index-advisor
-description: Recommend which indexes to add or drop for a connection, using DeepSQL's workload-weighted advisor, and optionally dry-run/apply them.
-version: 1.0.0
-platforms: [linux, macos, windows]
-metadata:
-  hermes:
-    tags: [index, indexes, advisor, performance, create-index, drop-index, unused, deepsql]
-    related_skills: [slow-query-optimize, workload-analysis]
----
-
-# Index Advisor
-
-Use when the user asks what indexes to add or drop, or "how do I speed up this workload with indexes?" Indexes are a **whole-workload** decision — never recommend one off a single query in isolation; that's what this advisor is for.
-
-## Procedure
-
-1. **Resolve the connection** (`list_connections` → UUID).
-
-2. **Get the workload-weighted recommendations.** `get_index_recommendations(connectionId)` returns the pre-computed top-N (default 5) ranked by net benefit (`Σ calls × mean_exec_time` − write cost). Each carries the contributing query fingerprints, the role each column played, and (on Postgres) a HypoPG cost-delta. This covers both `CREATE_INDEX` and `DROP_INDEX` (unused / redundant-prefix) candidates.
-
-3. **Add catalog context** when relevant: `get_index_health(connectionId)` for the overall picture, `get_unused_indexes` / `get_duplicate_indexes` for dead weight, `get_missing_indexes` for catalog-level suggestions, `get_table_index_usage(table)` for one hot table.
-
-4. **Explain each recommendation** in terms the user can act on: which queries it helps, expected benefit, and write-cost trade-off. Don't just dump the list.
-
-5. **Estimate impact before applying.** `apply_index_recommendation(recommendationId, mode="DRY_RUN")` (default) uses HypoPG on Postgres to install a virtual index and EXPLAIN the contributing queries — zero writes. Report the planner cost delta.
-
-6. **Apply only on explicit request, admin only.** `mode="APPLY"` (real `CREATE/DROP INDEX CONCURRENTLY`) or `APPLY_AND_MEASURE` (also runs `EXPLAIN ANALYZE` before/after) require `confirm: true`. The DDL is server-generated from the recommendation row — you never supply index SQL. Surface what will run and get a human OK first.
-
-## Guardrails
-
-- Recommend against an existing covering index/constraint instead of a redundant single-column one — `get_index_health` / `get_table_index_usage` will show it.
-- A `DROP_INDEX` recommendation for an "unused" index still deserves a sanity check: confirm with the user it isn't a rarely-used-but-critical path before applying.
-- `apply_index_recommendation` is the only write-capable MCP tool. Treat every `APPLY` like a production change.

package/agent-profile/skills/schema-exploration/SKILL.md

@@ -1,32 +0,0 @@
----
-name: schema-exploration
-description: Map or describe a database — what it tracks, its tables, relationships, and conventions — grounded in DeepSQL's cached schema and brain.
-version: 1.0.0
-platforms: [linux, macos, windows]
-metadata:
-  hermes:
-    tags: [schema, explore, tables, relationships, foreign-keys, describe, deepsql, database]
-    related_skills: [bi-query, workload-analysis]
----
-
-# Schema Exploration
-
-Use when the user wants to understand the database itself ("what does this DB track?", "what tables exist?", "how are orders and customers related?", "describe the bookings table").
-
-## Procedure
-
-1. **Resolve the connection** (`list_connections` → UUID) if you don't have it.
-
-2. **Get the shape.** `get_schema(connectionId)` for tables, columns, types, declared FKs. `get_database_objects(connectionId)` when you also need views/functions/procedures, not just columns. The schema is cached and authoritative — trust it over the codebase.
-
-3. **Get the meaning.** `get_brain_context(connectionId, "<what the user is asking about>")` for the domain layer: what the tables mean, business terms, documentation. This is what turns "a list of tables" into "what the database tracks."
-
-4. **Fill relationship gaps.** Many real databases lack declared foreign keys. `get_relationships(connectionId)` returns inferred + validated FKs with a `confidence` score and `validationStatus`. Report the confidence — a 0.95 inferred FK is reliable; a 0.4 one is a guess.
-
-5. **Surface the rules and traps.** `list_business_rules(connectionId)` and `get_anti_patterns(connectionId, kind="table")` so the user learns the conventions and known schema smells, not just the structure.
-
-## Reporting
-
-- Lead with **what the database is for**, then the largest/most central tables, then notable relationships.
-- For "largest tables," use the row counts from `get_schema` (don't run `COUNT(*)` across every table).
-- Flag anti-patterns and low-confidence inferred FKs explicitly — they're the things a user most needs to know and least expects.

package/agent-profile/skills/slow-query-optimize/SKILL.md

@@ -1,31 +0,0 @@
----
-name: slow-query-optimize
-description: Diagnose why a query is slow and propose a rewrite, using DeepSQL's plan analysis and AI query optimizer.
-version: 1.0.0
-platforms: [linux, macos, windows]
-metadata:
-  hermes:
-    tags: [slow, query, optimize, explain, plan, performance, rewrite, regression, deepsql]
-    related_skills: [index-advisor, workload-analysis]
----
-
-# Slow Query Optimize
-
-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.
-
-## Procedure
-
-1. **Resolve the connection** (`list_connections` → UUID).
-
-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`).
-
-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.
-
-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.
-
-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`.
-
-## Guardrails
-
-- 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.
-- A rewrite that changes result semantics is a bug, not an optimization. Preserve the business rules (filters, soft-deletes) the original query respected.

package/agent-profile/skills/workload-analysis/SKILL.md

@@ -1,36 +0,0 @@
----
-name: workload-analysis
-description: Explain what's driving database load — slow-query hotspots, regressions, per-customer load, and table growth — across the whole workload.
-version: 1.0.0
-platforms: [linux, macos, windows]
-metadata:
-  hermes:
-    tags: [workload, slow-queries, regression, hotspots, growth, anomaly, customers, deepsql]
-    related_skills: [slow-query-optimize, index-advisor]
----
-
-# Workload Analysis
-
-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`.
-
-## Procedure
-
-1. **Resolve the connection** (`list_connections` → UUID).
-
-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.
-
-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.
-
-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?"
-
-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.
-
-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`.
-
-## Guardrails
-
-- 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.
-- 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.
-- 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.
-- 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.
-- `get_query_samples` exposes literal bind values — treat the output as potentially sensitive data.

package/agent-profile/skins/deepsql.yaml

@@ -1,46 +0,0 @@
-# DeepSQL Agent — terminal skin (subtle mono grey). Rebrands the Hermes TUI/CLI.
-# Ships in the profile distribution under <profile>/skins/, activated via
-# `display.skin: deepsql` in the profile's config.yaml. The DeepSQL wordmark +
-# tagline live in the (vendored) TUI source (banner.ts / branding.tsx); this skin
-# drives colors + branding strings.
-name: deepsql
-description: DeepSQL Agent — subtle mono
-
-colors:
-  # Prominent elements (wordmark, "What I can do" header, category labels, ✨ Try)
-  # use a mid-tone MAROON/garnet — a saturated mid-luminance color contrasts with
-  # BOTH light and dark terminal backgrounds (pure greys vanish on one of them).
-  # Body text is a warm neutral. Wordmark gradient = primary→accent→border.
-  banner_border: "#8E3B4A"   # deep maroon  — wordmark bottom rows + panel border
-  banner_title: "#B14A5C"    # garnet       — wordmark top rows + the section header
-  banner_accent: "#8E3B4A"
-  banner_dim: "#A89BA0"      # warm mid-grey — prompts / metadata (readable on both)
-  banner_text: "#D2C7CB"     # warm light-grey — descriptions
-  ui_accent: "#CC6B7D"       # rose-maroon  — wordmark mid rows + labels + ✨ Try
-  ui_label: "#CC6B7D"
-  ui_ok: "#3FA796"
-  ui_error: "#E5484D"
-  ui_warn: "#E6B15C"
-  prompt: "#DDD4D7"
-  input_rule: "#5A4348"
-  response_border: "#5A4348"
-  status_bar_bg: "#1A1113"
-  status_bar_text: "#D2C7CB"
-  status_bar_strong: "#E8DDE0"
-  status_bar_dim: "#A89BA0"
-  status_bar_good: "#3FA796"
-  status_bar_warn: "#E6B15C"
-  status_bar_bad: "#E5484D"
-  status_bar_critical: "#E5484D"
-  session_label: "#A89BA0"
-  session_border: "#8E3B4A"
-
-branding:
-  agent_name: "DeepSQL Agent"
-  welcome: "DeepSQL Agent — ask about your database, or /help for commands."
-  goodbye: "Bye."
-  response_label: " DeepSQL "
-  prompt_symbol: "❯"
-  help_header: "Commands"
-
-tool_prefix: "│"

package/agent-profile/tui/HERMES_VERSION

@@ -1 +0,0 @@
-0.17.0