Skip to main content
Glama
deenesjakoruzh
wd041216-bit

cross-validated-search

by wd041216-bit
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Python MCP Jev License

Why Zero-API-Key Web Search (Jev-Powered)

An agent that searches the raw web pays for everything it reads: context tokens, latency, and attention spread over SEO noise. Zero-API-Key Web Search puts a sieve between search and the agent:

  1. Search the web with zero API keys (DuckDuckGo by default, self-hosted SearXNG for cross-validation, optional Bright Data for production SERP + Web Unlocker).

  2. Sieve the results through Laya — an open-weight (Apache-2.0), non-autoregressive decision model that scores every result for relevance in a single forward pass (~35 ms on GPU, 100–330 questions/sec batched) with calibrated probabilities. It never generates text, so there is nothing to parse and nothing to hallucinate.

  3. Verify claims with probabilistic stance classification (support / conflict / neutral per source) instead of pure keyword matching, then emit citation-ready evidence reports.

Every stage degrades gracefully: no Laya installed? The pipeline falls back to the lexical heuristic verifier and still works — Laya is an accelerant, not a dependency.

 query ──► providers ──► cross-validate ──► ┌─────────┐ ──► LLM context pack
                                           │  LAYA   │      (citations only)
                                           │  SIEVE  │
                 noise ───────────────────►└─────────┘ ──► verify_claim
                 (dropped pre-context)                    (probabilistic stance)

Related MCP server: agent-knowledge

30-Second Setup

pip install zero-api-key-web-search          # free search, no API key, no model download

zero-search "Python 3.13 release" --json
zero-verify "Python 3.13 is the latest stable release" --deep --json
zero-report "Python 3.13 stable release" --claim "Python 3.13 is the latest stable release" --json

Add the Sieve (Optional, ~800 MB, Fully Local)

pip install "zero-api-key-web-search[laya]"   # pulls laya + torch

# Relevance-filter every search result before it reaches your agent
zero-search "react state management" --laya --laya-threshold 0.6 --json

# Probabilistic stance verification (laya-stance-v1 model)
zero-verify "Python 3.13 is the latest stable release" --laya --json

# Both, in the flagship evidence report
zero-report "gpt-5 release" --claim "GPT-5 is released" --laya --deep --json

On Apple Silicon it runs on MPS; on NVIDIA GPUs on CUDA; anywhere on CPU (slower but works). Behind a network that can't reach Hugging Face? export HF_ENDPOINT=https://hf-mirror.com.

What Laya does inside the pipeline

Stage

Question asked (one forward pass per item)

Effect

--laya on search/context

"Is this result relevant and informative for the query?"

drops noise before it burns context tokens

--laya on verify/report

"Does this text support the claim?" + "Does it state or imply the claim is false?"

replaces regex conflict markers and keyword-overlap cutoffs with calibrated probabilities

The verification blend becomes 0.55 × neural stance + 0.35 × source quality + 0.10 × freshness (vs. the lexical model's 0.45 × keyword overlap + …). The result payload keeps the full lexical sidecar so you can compare both classifiers on your own data.

Checkpoints

Subfolder

Backbone

Best at

root (default)

ModernBERT-large 421M

English text

multilingual

mmBERT-base 322M

100+ languages, ~2× faster

typed-decisions

ModernBERT-large 421M

workflow-tuned decisions

zero-verify "..." --laya --laya-subfolder multilingual   # non-English claims

MCP Server (8 tools)

{
  "mcpServers": {
    "zero_api_key_web_search": {
      "command": "zero-mcp",
      "args": []
    }
  }
}

search_web, llm_context, browse_page, verify_claim, evidence_report, list_providers, clear_cache, setup_providers — the first four accept "laya": true and "laya_threshold" so a Claude/Cursor/any-MCP agent can opt into the sieve per call.

Provider Paths: Free to Production

Path 1 — Free (zero configuration). DuckDuckGo, no account:

zero-search "Python 3.13 release" --json

Path 2 — Free cross-validated. Self-hosted SearXNG for dual-provider corroboration (see docs/searxng-self-hosted.md):

./scripts/start-searxng.sh
export ZERO_SEARCH_SEARXNG_URL="http://127.0.0.1:8080"
zero-search "AI regulation" --profile free-verified --json

Path 3 — Production SERP. Bright Data for 7 engines (Google, Bing, DuckDuckGo, Yandex, Baidu, Yahoo, Naver), geo-targeting, structured results:

zero-setup   # interactive wizard
zero-search "news" --provider brightdata --engine google --type news --region us-en --json

Path 4 — Production + Web Unlocker. 403/429/CAPTCHA/geo-blocked pages auto-retried through the Web Unlocker on zero-browse.

Engineering

  • Circuit breaker per provider (3 consecutive failures → 60 s cooldown)

  • Response cache for searches and pages, clear_cache included

  • Async + threaded provider fan-out; goggles-style reranking presets (docs-first, research, news-balanced)

  • Claim decomposition for compound statements, sub-claim verdicts

  • Page-aware verification (--deep): fetch top pages and re-score

  • Graceful degradation everywhere: Laya missing → lexical verifier; provider down → next provider; page blocked → unlocker; unlocker off → snippet-only

  • 111 tests passing (python -m pytest tests/ -q)

Honest Limits

Read docs/trust-model.md before trusting any verdict. The short version:

  • The lexical verifier (evidence-aware-heuristic-v3) is pattern-matching, not entailment — it is transparent and fast, and blind to paraphrase, negation scope, and mismatched numbers. Laya mode (laya-stance-v1) fixes the class of failure, not the possibility of failure.

  • Laya ships over-confident. Upstream measured mean ECE 0.466 → 0.081 only after per-domain temperature refitting. Our defaults (threshold 0.5) are reasonable, not calibrated — sweep --laya-threshold against a small labeled set from your domain before production use.

  • Laya's base checkpoints are a fast base to specialise, not a zero-shot oracle (upstream's own typed-decisions benchmark: 0.362 zero-shot vs 0.766 fine-tuned; XNLI-style tasks are much stronger). For high-stakes domains, fine-tune the open checkpoint on your workflow and drop it in via --laya-model / --laya-subfolder.

  • High-cardinality option sets (>20 options per question) are Laya's weak spot; Zero-API-Key Web Search only asks 1–2-option yes/no questions per item, which stays in its comfort zone.

  • Verification quality still depends on what search returns: no web footprint → insufficient_evidence, by design.

Attribution

The Jev-powered sieve integration uses Laya by Convai Innovations (Apache-2.0, open weights) — an open Jev-class, non-autoregressive decision model. Search providers, the verification pipeline, the MCP server and the CLI are original to this project (MIT).

License

MIT — see LICENSE.

Available Tools

2 tools
browse_pageA

Fetch and extract pure text content from a specific URL. Use this to read the full content of a page found via search_web.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL of the webpage to read.
max_charsNoMaximum number of characters to extract. Default is 10000.

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only mentions 'pure text content' but lacks details about handling of dynamic content, redirects, errors, or rate limits, which are important for a fetch tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The purpose is front-loaded, and the sentence about usage adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 2 parameters and no output schema, the description is mostly adequate but could benefit from mentioning behavior like page size limits or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning to parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fetch and extract' and the resource 'pure text content from a specific URL', and explicitly differentiates from sibling tool search_web by specifying usage after searching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for when to use ('to read the full content of a page found via search_web'), though it does not explicitly state when not to use or list all alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_webA

Search the web for real-time information, news, images, books, or videos. Always use this to verify facts or get up-to-date information before answering.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe search query.
typeNoType of search. Default is 'text'. Use 'news' for current events.text
regionNoRegion code (e.g., 'wt-wt' for global, 'us-en' for US English, 'zh-cn' for China). Default is 'wt-wt'.wt-wt
timelimitNoTime limit for results: 'd' (day), 'w' (week), 'm' (month), 'y' (year). Leave empty for no limit.

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description only states it searches the web, but does not disclose behavioral traits like rate limits, result format, or any side effects. As a search tool with no annotations, more behavioral context is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose, second gives usage guidance. No unnecessary words, front-loaded with key action and context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and description does not explain expected return format (e.g., list of results). While basic search tool expectations may suffice, explicit mention of output would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage for all 4 parameters. Description does not add significant meaning beyond what schema already provides; it summarizes the type parameter briefly. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'search', resource 'web', and enumerates content types (real-time information, news, images, books, or videos). Distinguishes from sibling 'browse_page' which is likely for loading a specific page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Always use this to verify facts or get up-to-date information before answering', giving clear context for when to use. Does not explicitly state when not to use vs. browse_page, but it is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedbrowse_page
    • First observedsearch_web
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: search_web handles queries, browse_page retrieves page content. No overlap.

Naming Consistency5/5

Both tools use a consistent verb_noun pattern (browse_page, search_web), making them predictable.

Tool Count3/5

Only 2 tools for a search server is minimal but functional for basic web search and page retrieval. Slightly under-scoped.

Completeness3/5

Covers search and content retrieval, but lacks specialized search types (images, news, etc.) or filtering options, which are mentioned in search_web description but not provided as separate tools.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • LastSearch-AI

    LastSearch-HQ
    A
    license
    A
    quality
    A
    maintenance
    Evidence-backed web research for AI agents. Real-time search with cited claims, confidence scores, and compare mode showing raw LLM hallucination vs evidence-backed answers.
    5
    20
    Apache 2.0

  • agent-knowledge

    yucx-go
    A
    license
    A
    quality
    C
    maintenance
    Long-term memory for AI agents. Compiles conversations into a structured knowledge base with Claim/Evidence model, source provenance, append-only timeline, and contradiction detection. Multi-path retrieval (Exact + BM25 + Graph + weighted RRF + reranker) — 96.6% R@5 on LongMemEval-S, zero vector dependencies.
    8
    3
    MIT

  • memotrust

    Idanref
    A
    license
    Not graded
    quality
    C
    maintenance
    Verified memory for AI agents — agents propose memories that are quarantined until verified against evidence, and recall() returns only trusted, fresh, and in-scope facts, preventing poisoned or hallucinated data from spreading.
    13 npm
    1
    MIT