What it does

ktx runs locally as a CLI tool and MCP server. It scans your warehouse (Postgres, Snowflake, BigQuery, etc.), ingests dbt/Looker/Metabase/Notion sources, builds a searchable wiki and YAML semantic layer, then exposes that context to agents. When an agent asks “what’s Q3 revenue?”, ktx returns approved metric definitions and compiles read-only SQL rather than letting the model guess joins and filters.

The interesting bit

The project treats “context” as executable, not just documentation. It auto-detects joinable columns, resolves fan and chasm traps in the join graph, and flags contradictions across your wiki and semantic sources for human review. That’s the unglamorous plumbing that usually breaks agent-generated queries.

Key highlights

• Runs entirely local; no hosted service, no extra billing beyond your own LLM keys
• Read-only by design; agents cannot write to the warehouse through ktx
• Ingests and reconciles across dbt, MetricFlow, LookML, Metabase, Notion, and raw tables
• Ships CLI + MCP server for Claude Code, Codex, Cursor, OpenCode
• Python query planner (python/ktx-sl) plus TypeScript CLI/context engine in one pnpm+uv workspace

Caveats

• Requires an existing SQL warehouse; useless without one
• Setup involves configuring providers, connections, and running ingestion before agents can query accurately
• Telemetry is on by default for CLI runs (anonymous, but still opt-out rather than opt-in)

Verdict

Worth a look if your analytics team is tired of agents returning “revenue” numbers that don’t match dbt. Skip it if you just need occasional ad-hoc queries or lack a warehouse to point it at.