Ktx analytics

--- name: ktx-analytics description: Use this when answering a question that requires data from a database connected to ktx:such as investigating, analyzing, responding to "how many," "show me," or "what's the breakdown of" requests, finding records by value, exploring tables, comparing time periods, explaining metrics, or handling any data analysis request. Triggers even when the user does not say "analytics"; if the answer requires querying a configured ktx connection, this skill applies. --- # ktx Analytics Workflow You have access to ktx-MCP-tools for data discovery, semantic-layer analysis, raw read-only SQL, wiki context, and memory ingest. Follow this workflow. <workflow> 1. Discover - First, call discover_data to see what exists across wiki pages, semantic-layer sources, metrics, dimensions, raw tables, and columns. Returns refs only. 2. Inspect top hits in parallel - For each promising ref: - kind: 'wiki' -> wiki_read - kind: 'sl_source', kind: 'sl_measure', or kind: 'sl_dimension' -> sl_read_source - kind: 'table' or kind: 'column' -> entity_details 3. Resolve business values - if the user specified a value such as "Acme Corp," "enterprise," or "status=shipped," call dictionary_search to determine which column contains it. 4. Plan the analysis:identify the granularity, metrics, dimensions, filters, time window, and expected row limits before querying. 5. Query: - Prefer sl_query when the semantic layer covers the question. - Use sql_execution only for questions the semantic layer does not cover. 6. Validate and explain:perform a sanity check on totals, filters, null handling, and time zones. Specify the source tables or semantic-layer objects used. 7. Capture lasting insights - call memory_ingest whenever a session yields something worth remembering (business rules, metric definitions, schema pitfalls, recurring findings) or whenever the user asks you to remember something. Pass Markdown-content, including any source context that the memory-agents should consider. Each call is a feedback loop; better notes today mean smarter discover_data and wiki_search results tomorrow. </workflow> <rules> - Always run discover_data before writing SQL. Do not guess table names. - Prefer the semantic layer over raw SQL when both can answer the question; measures are the source of truth. - Read entity details before writing SQL against an unfamiliar table. Do not assume column names. - Treat sql_execution as read-only. Writes are rejected by the server. - Validate value mentions using dictionary_search instead of guessing case or spelling. Treat a missing value in the “dictionary_search” as non-authoritative. The index is built from profile-sampled values, so a missing value may simply have been outside the sample. Follow up with sql_execution against the most plausible columns before concluding that the value is absent. - When connection_list shows multiple connections, connectionId scoping: - Always pass it: entity_details, sl_read_source, sql_execution. - Pass it when the intent pins a warehouse; otherwise, omit it for unscoped discovery: sl_query, discover_data, dictionary_search. - memory_ingest: pass it for warehouse-specific knowledge (e.g., “in our warehouse”); without it, the memory entry is treated as wiki-only and cannot update the semantic layer. - Never pass it: connection_list, wiki_search, wiki_read, memory_ingest_status. - If scoping is required but the intent is ambiguous, ask which warehouse before calling. - Display compact result tables for small outputs. For broad results, summarize the top findings and mention the applied limit. - Ask for a concise clarification only when the metric, date range, entity, or grain is genuinely ambiguous and cannot be inferred from context. </rules> <examples> Input: "How many orders did Acme Corp place last month?" Workflow: 1. dictionary_search({ values: ["Acme Corp"] }) finds customers.name. 2. discover_data({ query: "orders customer monthly" }) finds an “orders” semantic-layer source. 3. sl_read_source({ connectionId: "warehouse", sourceName: "orders_facts" }) confirms the source’s grain, measures, and dimensions. 4. `slquery({ connectionId: "warehouse", measures: ["ordercount"