Keenable SELECT: Run SQL Queries on Web Search Results

Keenable SELECT is an MCP server that runs read-only DuckDB SELECT queries on live web data. Instead of the traditional agent flow—search, fetch each result, read pages, then synthesize—SELECT moves the work into SQL. One call can search over 1,000 pages, filter them with an exact WHERE clause at no LLM cost, and extract structured fields with a small LLM call per row.

How it works

You ask a question like: "Which AI researchers moved between frontier labs since 2025? For each move list the researcher, the lab they left, where they went, and the month." Keenable SELECT translates that into SQL:

SELECT SEM_EXTRACT(content, 'researcher'),       SEM_EXTRACT(content, 'left lab'),       SEM_EXTRACT(content, 'joined lab'),       SEM_EXTRACT(content, 'move month')FROM WEB_SEARCH(8 diverse queries)WHERE SEM_MATCH(content, 'named researcher moving between frontier labs, 2025+')

The server executes the search, runs semantic operators, and returns a report. Each result includes a full trajectory: every query, tool result, and result set behind the final output.

MCP tools

• select — runs a DuckDB SELECT and returns rows. Result sets are saved with IDs for reuse in later queries.
• generate_html_report — takes a brief and result set IDs, then renders a shareable HTML report.

Semantic operators

The operators live inside SQL. The server finds them in the parsed statement, runs them, and replaces them with plain columns. Exact SQL filters execute first, so only surviving rows go to the LLM operators—saving tokens.

• WEB_SEARCH('q1', 'q2', ...) — searches all queries concurrently, merges ranked results, dedupes URLs.
• WEB_FETCH('https://a.com', ...) — fetches pages as Markdown, one row per page.
• SEM_EXTRACT(column, 'field description') — one LLM call per row; returns a field or null.
• SEM_EXTRACT_ALL(column, 'what one value is') — returns all matching values as a list.
• SEM_MATCH(column, 'predicate') — LLM test per row (e.g., filtering).

Why it matters

Traditional web search gives an agent ten links. The agent must read each page and spend expensive tokens building an answer. SELECT moves that work into the query layer—searching thousands of pages, filtering them exactly, and extracting fields with minimal LLM calls. The gallery shows reports like "Twenty Years of YC Startup-Name Morphology" (36 messages, 18 queries) and "Orbital Launch Atlas, 1957–2026" (16 messages, 9 queries), each with full trajectories.

If you're building agentic search or data-heavy research tools, this is a different pattern worth studying: SQL as the control plane, LLM only for semantic extraction and matching.