Skip to content
Tech News
← Back to articles

Show HN: Scry, programmable internet search w/ congestion pricing

read original more articles
Why This Matters

Scry is positioned as a search backend built specifically for AI agents rather than humans, offering programmatic access via MCP or HTTP with structured schemas and freshness controls like rolling web crawls. This matters because it signals a growing trend of infrastructure being built explicitly for agentic AI workflows, with novel pricing models like 'congestion pricing' to manage demand from automated systems.

Key Takeaways

Claude Code, Codex, Cursor, or any MCP client connects with the same URL. Agents without an MCP client use the HTTP API with your key. Per-client steps live on the connect page.

read the prompt text first

Scry: programmatic search over the public web, for agents. Connect over MCP (preferred). Scry is an MCP server at https://mcp.scry.io. One URL, OAuth on first use, approve at scry.io. - Claude Code: claude mcp add --transport http scry https://mcp.scry.io then run /mcp inside a session and approve. - Codex: codex mcp add scry --url https://mcp.scry.io && codex mcp login scry - Claude.ai, Claude Desktop, ChatGPT (developer mode), Cursor, any MCP client: add a custom connector with that URL and approve the scry.io consent. - No browser (CI, headless): Claude Code adds --header "Authorization: Bearer $SCRY_API_KEY"; Codex adds --bearer-token-env-var SCRY_API_KEY. Keys live in the dashboard at https://scry.io/dashboard. - Tools: the roster is whatever tools/list returns; whoami {roster: <fingerprint>} tells a client whether its cached list is current. Call schema {mode: contract} once before writing SQL: that document carries the product contract and starter guidance (the bare call is the relation index; each relation carries its stats). For "what does the fresh web say since my cutoff": embeddings.crawl_pages is a rolling fresh crawl of allowlisted high-information hosts whose observed_on is the day the page was observed — mint an @handle with embed, rank it with the vector helper, and add `WHERE observed_on > toDate('<your cutoff>')`; hydrate verbatim text from crawl.pages by url. HTTP API (when MCP is not available). Base https://api.scry.io; send `Authorization: Bearer $SCRY_API_KEY` (load it from `~/.config/scry/env`). No key: stop and send the user to https://scry.io/dashboard. - GET /v1/scry/context?mode=agent — the live contract. - GET /v1/scry/schema — the only discovery authority. The default document carries full contracts for the start-here relations plus a compact index of the rest; `?relation=<name>[,<name>]` fetches more full contracts; `?mode=index` lists the whole catalog. Schema discovery is also one SQL call: `scry.relations` and `scry.columns` are the same catalog served as relations you can filter and join, e.g. SELECT relation FROM scry.columns WHERE name = 'author_id' LIMIT 100. Never guess column names; a wrong-column error returns the real roster. - POST /v1/scry/query with `Content-Type: text/plain` — one read-only statement in Scry SQL, always with LIMIT (start at 20). Synchronous; long queries may stream whitespace before the JSON body. `WITH RECURSIVE` is served (`anchor UNION ALL step`, the CTE read only in the step's FROM/JOIN; a 111-iteration branch-on-state loop returns in ~100 ms, measured 2026-09-15) — each iteration rescans what the step joins, so declare `x-scry-max-seconds` on corpus-scale joins. A JSON body `{"program": {...}}` on the same route runs fixpoint graph walks that read only the frontier: citation, reply/quote, and thread-tree edges, in-walk filters, stratified negation, zero-egress per-depth counts. Docs: https://scry.io/docs/turing-complete-search; the calculus it implements: https://scry.io/docs/calculus-of-search. - POST /v1/scry/rerank — order documents you already hold by an instruction. - POST /v1/scry/compile with a JSON body — `q` (one search-grammar line) and `relation`, compiled to that relation's own statement without running it; `relation` set to `*` compiles every relation with a text plane. Working rules - Token filters run at the speed of their rarest token: include one distinctive token (a name, an identifier, an unusual word). All-common-word sets scan for 30-60s. For broad topics use the embedding helpers the schema advertises. - Text lives in source-native relations (reddit.comments, hackernews.items, forums.posts, bluesky.posts, crawl.pages, books.passages and their peers; schema lists every one), each under its own columns and clock, not in one uniform corpus: decide which source families could answer and read those relations directly or in parallel, one statement each or a UNION ALL of two or three. Allocating the search — which relations, how selective a predicate, how much compute the question deserves — is your work, and the schema catalog, a time window, and explain are the primitives for it; a broad low-selectivity scan costs its relation's full read, so spend it where the answer can be. - To sort rows by an attribute you can describe, send `x-scry-rerank: <directive>` on POST /v1/scry/query (MCP: the rerank argument on sql). Runs on local models, $0; the response's rerank block says what applied. - To see what a statement would touch before paying for it, send `x-scry-explain: 1` on POST /v1/scry/query (MCP: explain=true on sql): the response is the plan and index analysis — parts and granules selected per index, reads named by relation — the referenced relations, and a forecast (rows, bytes, seconds, memory, and the share of each relation the predicates keep), and the statement does not run — with one exception: an ANN statement runs its lane search during explain to find the candidates the rerank is planned over (`ann.lane_ms`, folded into the forecast as `lane_seconds`; the run pays it again). - Use only relations and helpers the live schema returns; an omitted name is unavailable, and there is no fallback database. - Use is governed by https://scry.io/legal/terms: no bulk redistribution of results, no reconstruction of a substantial portion of a corpus, no building a competing corpus, index, or dataset product from what the service returns. Public work built on Scry (published research, articles, datasets, demos, open-source tools, products) credits Scry visibly, in the work or its documentation, with a link to https://scry.io. - Keep source timestamp, observation time, load time, processing status, and quality fields distinct. A recent load is not a recent source event; an absent row is not source absence. Say which fields support each claim. - Report the exact SQL, relations, row count, duration, truncation state, and accounting fields returned. Example claude mcp add --transport http scry https://mcp.scry.io curl -s https://api.scry.io/v1/scry/query \ -H "Authorization: Bearer $SCRY_API_KEY" \ -H "Content-Type: text/plain" \ --data "SELECT hn_id, title, original_author, original_timestamp, uri FROM hackernews.items WHERE hn_id >= (SELECT max(hn_id) AS n FROM hackernews.story_scores WHERE observed_on >= today() - 7) - 100000 AND title != '' ORDER BY hn_id DESC LIMIT 20"