Startup Keenable has renamed its tool Web Query Language (WebQL) to Keenable SELECT and opened public access to it. The product allows executing read-only SQL queries against the live web over DuckDB, combining precise filtering with semantic operators, and returns tables of fields with links to sources instead of a usual wall of links. Access is free until the end of September — with a limit of two concurrent sessions.

image

What happened

The product, previously known as Web Query Language (WebQL), is structured as an MCP server with two methods: select executes a single read-only SQL statement against the live web over DuckDB, and generate_html_report publishes a ready-made HTML report with tables and sources. The SQL dialect has built-in operators WEB_SEARCH and WEB_FETCH, as well as semantic SEM_EXTRACT, SEM_MATCH, SEM_SCORE, and SEM_NORM; precise filters trigger before LLM operators, so, according to the developer's claim, a single query can bypass more than 1000 pages, and per-row semantic processing is paid for only for surviving rows. The result of each query is saved as a named result set, on which subsequent queries and the report agent rely; the research itself is conducted by a research agent on the large model Sol, and reports are generated by the server model Fable. The tool is available in the Claude connectors catalog and connects to Claude Code, Codex, and Cursor; in the showcase gallery, 24 examples with full query trajectories have already been published.

Context

The "web as a table" pattern emerged as a response to the economics of agentic research: in the classic cycle, search returned about ten links to the agent, and a large model spent expensive context on reading each one in turn. SELECT moves this reading inside the SQL engine, reproducing on the web corpus the classic selectivity-first optimization from databases: first, cheap precise operations are performed, and only surviving rows are subjected to expensive semantic computations — one call to a small proprietary model per row. The layer is built on top of the open MCP protocol, so any compatible agentic clients can work with it, not just one closed product. It is also notable that each run leaves a verifiable trail: named result sets and full query trajectories in the examples gallery — a rare level of transparency for products.

Why this matters for the industry

For the industry, the main shift is that reading search results moves from the agent's expensive context into the query itself: with high filter selectivity, both context consumption and the cost of deep web crawling decrease, because the large model no longer reads each link in turn. This is a practical standardization of the "web as a table" pattern on top of the open MCP protocol — a step towards turning the "agent reads links" stage into a cheap tabular primitive in agentic architectures. For builders, SELECT is a ready-made "search plus field extraction" backend: there is no need to assemble your own wrapper around search APIs and extractors, and named result sets allow building multi-step pipelines and dashboards. Since MCP makes copying cheap, if the pattern takes hold, similar semantic SQL layers to the web and data lakes are likely in other stacks, and the SEM_EXTRACT and SEM_MATCH operators can become a benchmark for comparison.

Why this matters for users

The window for free experiments is open until the end of September with a limit of two concurrent sessions. You can ask a question in natural language on the page https://app.keenable.ai/select/start, and the MCP server https://select.keenable.ai/mcp connects with a single claude mcp add command in Claude Code, Codex, or Cursor — the result will be tables of fields with sources instead of a wall of links. The limit is enough for prototypes and pet projects. Typical tasks — LLM release timelines, atlases, org charts — have already been broken down in the showcase gallery, where the number of messages and SQL queries is indicated for each run; based on these trajectories, you can calibrate expectations and check in the evening on your own tasks how much deep web crawling actually costs.

What is still unknown / limitations

Key claims remain vendor declarations without methodology: the figure of "more than 1000 pages" is not supported by a disclosed distribution of filter selectivity, crawl stopping criteria, and a definition of what is considered a passed page. There are no public benchmarks for the quality of web-as-table extraction; the extractor is a small proprietary model with undisclosed sizes and origins, and the architectures and quality metrics of the Sol and Fable models have not been published. The showcase gallery was compiled by the developer themselves without disclosed task selection criteria, so it cannot be used to judge the average complexity of a run. Pricing after the end of the free period and the product's behavior under production load are unknown; open questions remain about the reliability of SEM operators on a non-stationary web and the resilience of the chain to prompt injection from downloaded pages.

Sources

Author

Look at AI, editorial team