What can you do with this server?

This server is an MCP tool for web research: it fetches web pages and uses a local Ollama LLM to answer questions about their content. * analyze_page(url, question) — Fetches a given URL, extracts the full page content, and answers a question about it; long pages are auto-split and analyzed with map-reduce so nothing is skipped. * search_site_and_analyze(site, phrase, question, max_results) — Searches a site via DuckDuckGo's site: operator for pages containing a phrase, then analyzes each matching page to answer the question. * list_available_models() — Lists the Ollama models available on the configured server. * Works with any Ollama model (default qwen3:14b), not tied to a specific model family. * Robust content extraction via trafilatura, independent of site layout/CSS selectors. * Supports multiple MCP transports: stdio, SSE, and streamable-http. * Configurable via environment variables for Ollama host/port/model and HTTP bind settings. * Can run locally or via Docker; integrates easily with MCP clients like Open WebUI. * Reports progress during long operations to prevent client timeouts.

Which integrations are available for this server?

Integrates with DuckDuckGo's site search to find pages on a given domain containing a phrase. Uses local Qwen models via Ollama to extract answers and analyze page content.

How do I use qwen-web-research-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@qwen-web-research-mcp analyze https://en.wikipedia.org/wiki/Artificial_intelligence and summarize key points" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

qwen-web-research-mcp

by frankjony17

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

web-research-mcp

MCP server for web research: given a URL (or a site + phrase to search), it fetches the full page content, and uses a local LLM (via Ollama — any model you have pulled, not tied to a specific model family) to extract/answer a question about it. Long pages are automatically split into chunks and analyzed with a map-reduce strategy, so nothing is skipped.

Content extraction uses trafilatura, which strips navigation/ads/boilerplate based on content heuristics rather than site-specific CSS selectors — so it keeps working if a site's layout changes. Site-scoped search uses DuckDuckGo's site: operator, so any domain works without custom scraping code per site.

Tools

analyze_page(url, question) — fetch a page and answer question about its full content.
search_site_and_analyze(site, phrase, question, max_results) — find pages on site containing phrase, then run analyze_page-style extraction on each match.
list_available_models() — list the models available on the configured Ollama server.

Related MCP server: searxng-mcp

Requirements

Python 3.11+
An Ollama server with at least one model pulled (defaults to qwen3:14b, but any Ollama model works)

Configuration (environment variables)

Variable	Default	Description
`OLLAMA_MODEL`	`qwen3:14b`	Ollama model to use
`OLLAMA_PORT`	`11434`	Port of the Ollama server
`OLLAMA_HOST_IP`	auto-detected	Override the Ollama host IP. If unset, it's read from `ip route show default` (useful when running inside WSL and Ollama runs on the Windows host)
`MCP_TRANSPORT`	`stdio`	`stdio`, `sse`, or `streamable-http`
`MCP_HOST`	`127.0.0.1`	Bind host (HTTP transports only)
`MCP_PORT`	`8000`	Bind port (HTTP transports only)

Run locally

python3 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/python -m web_research.server

Run with Docker

docker build -t web-research-mcp .
docker run -p 8001:8000 \
  -e MCP_TRANSPORT=streamable-http \
  -e MCP_HOST=0.0.0.0 \
  -e OLLAMA_HOST_IP=host.docker.internal \
  web-research-mcp

Or as a service in a docker-compose.yml alongside other tools (e.g. Open WebUI):

web-research:
  build: ./web-research-mcp
  ports:
    - "8001:8000"
  extra_hosts:
    - "host.docker.internal:host-gateway"
  environment:
    - MCP_TRANSPORT=streamable-http
    - MCP_HOST=0.0.0.0
    - MCP_PORT=8000
    - OLLAMA_HOST_IP=host.docker.internal
    - OLLAMA_MODEL=qwen3:14b

Then point your MCP client (e.g. Open WebUI's Tools/Connections settings) at http://web-research:8000/mcp (internal Docker network) or http://localhost:8001/mcp (from the host).

Available Tools

3 tools

analyze_pageA

Fetch a web page, and use a local Qwen model to extract/answer question about its full content. Long pages are automatically split into chunks and analyzed piece by piece (map-reduce), so no content is skipped.

Reports progress while working (page fetch retries, per-chunk analysis), so a client that respects MCP progress notifications won't time out waiting on a long page -- this can take 30s-3min or more.

Args: url: The page to fetch and analyze. question: What to extract or answer about the page's content.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`question`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description takes on full burden. It thoroughly discloses behavior: uses local Qwen model, splits long pages into chunks (map-reduce) to avoid skipping content, reports progress (page fetch retries, per-chunk analysis), and warns about long execution time (30s-3min). This is highly transparent.

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?

The description is concise, with each sentence adding value. It front-loads the core function, then explains special behavior (chunking and progress) and a clear Args section. No redundant phrases.

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

Completeness5/5

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

Given the tool's moderate complexity (2 params, output schema exists, no annotations), the description covers all essential aspects: purpose, parameters, behavior (chunking, progress), and time expectations. The presence of an output schema reduces need for return value details. It is complete.

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

Parameters5/5

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

Schema coverage is 0%, but the description provides clear meanings for both parameters: 'url' is the page to fetch/analyze, and 'question' is what to extract or answer. This compensates fully for the lack of schema descriptions.

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 specifies a clear action: fetching a web page and using a Qwen model to extract/answer a question about its content. It distinguishes itself from siblings by focusing on a single URL analysis, whereas search_site_and_analyze implies searching first, and list_available_models is about models.

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 clearly states when to use: to fetch a specific page and answer a question about its content. It implicitly contrasts with search_site_and_analyze by mentioning 'a web page' (single URL) vs. site search. However, it does not explicitly mention alternatives or when not to use it, but the context is clear.

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

list_available_modelsA

List the Qwen/Ollama models currently available on the local Ollama server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral aspects such as side effects, permissions, or whether it is read-only, relying solely on the verb 'list' to imply non-mutating behavior.

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?

The description is a single, concise sentence that front-loads the purpose without superfluous details.

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

Completeness5/5

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

Given the tool's simplicity (no parameters, no output schema), the description sufficiently conveys the operation and its scope, meeting all necessary contextual requirements.

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

Parameters5/5

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

There are no parameters to explain; the description is complete and needs no additional parameter information.

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 action (list) and the resource (Qwen/Ollama models) within a specific context (local Ollama server), distinguishing it from sibling tools that focus on page analysis and search.

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

Usage Guidelines2/5

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

The description does not specify when to use this tool versus alternatives, lacking explicit guidance on conditions or comparisons with sibling tools.

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

search_site_and_analyzeA

Search a specific site for pages/listings containing phrase, then run analyze_page-style extraction on each match to answer question.

Works on any site without site-specific scraping code: it uses DuckDuckGo's site: search to find matches, then trafilatura + Qwen to read and filter each page's content, so it keeps working even if the site's layout changes.

Each match takes roughly 30s-3min to fetch and analyze (more for long pages), so a large max_results will take proportionally long to return. Progress is reported per match and per chunk, for MCP clients that respect it.

Args: site: Domain to search within, e.g. "example.com". phrase: Exact phrase the publication/listing must contain. question: What information to extract from each matching page. max_results: Max number of matching pages to analyze (default 5).

ParametersJSON Schema

Name	Required	Description	Default
`site`	Yes
`phrase`	Yes
`question`	Yes
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full transparency load. It successfully discloses the core behaviors: uses external search engine, parsing through trafilatura and Qwen, handles layout changes, reports progress per match/chunk, and has long latency per match. It does not mention possible rate limits, no-match behavior, failure modes, or network auth, but covers most relevant behavioral traits for an AI agent considering this 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?

The description is well-structured into a high-level workflow, mechanism, performance note, and Args section. Every sentence contributes useful information such as time estimates, layout-resilience, or parameter semantics. It is concise without sacrificing essential guidance, and the 'Args:' list makes scanability easy.

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

Completeness5/5

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

For a multi-step search-and-analysis tool, the description covers when to use it, how it works, what each parameter means, time cost, progress reporting, and the fact that output follows analyze-style extraction. Because an output schema exists, avoiding return-value detail is appropriate. The description provides enough for an agent to decide if this tool is appropriate and set expectations about runtime.

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

Parameters4/5

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

The input schema has 0% description coverage, so the description is responsible for parameter meanings. It provides meaningful explanations for all four params: `site` with an example domain, `phrase` as an exact phrase, `question` as what info to extract, and `max_results` as maximum matching pages with a default of 5. This fully bridges the schema gap, though some examples or constraints are minimal.

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 opens with a specific, action-oriented phrase: 'Search a specific site for pages/listings containing `phrase`, then run `analyze_page`-style extraction on each match to answer `question`.' This clearly defines the tool's responsibility and differentiates it from the sibling tool `analyze_page`, which focuses on a single page. The scope (site-level search plus extraction) is unambiguous.

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?

The description explicitly explains when to use it ('Works on any site without site-specific scraping code'), how it works (DuckDuckGo `site:` search, trafilatura + Qwen), and yields a practical performance caveat: 'Each match takes roughly 30s-3min to fetch and analyze.' It does not explicitly name an alternative for single-page analysis, though it references `analyze_page`-style extraction, so it provides clear context but no explicit 'when not to use' statement.

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.

3 tool updatesv0.1.0Aug 20, 2026
- First observedanalyze_page
- First observedlist_available_models
- First observedsearch_site_and_analyze

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

A4.1/5.0

Scored 2026-08-20 14:10 across 3 tools

Disambiguation5/5

The two analysis tools are cleanly separated by input: analyze_page targets one explicit URL, while search_site_and_analyze first discovers matching pages on a domain and then analyzes them. list_available_models is clearly a separate utility, so there is no real ambiguity between tools.

Naming Consistency4/5

All names use snake_case and lead with a verb, making the set predictable and readable. The main deviation is that search_site_and_analyze combines two actions into one name, while the other tools use a simpler verb_noun pattern.

Tool Count4/5

Three tools is small but defensible for a focused web-research helper: two research workflows plus a model discovery utility. It is slightly minimal, but there is no obvious bloat or unnecessary duplication.

Completeness3/5

The server covers single-page analysis and site-scoped search, which are useful core pieces. However, it lacks a general web-search flow or multi-site research capability, so open-ended web research requests would have no obvious tool to use.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Keenable Web Search A
ai.keenable.api
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Research & Data Search Web Scraping
23
Jina Reader A
io.github.pipeworx-io
Jina AI Reader/Search MCP — turn any URL into clean LLM-ready markdown, plus web search.
Web Scraping Search
382
fetch-extract
io.github.CedricKouma
MCP server (stdio): fetch web pages as clean readable markdown via the AgentForge API
Browser Automation Web Scraping
2

Related MCP Servers

nesift-mcp
RAG Systems Search Web Scraping
scottgl9
A
license
Not graded
quality
D
maintenance
MCP server for local semantic search over web content, enabling AI agents to ingest, index, and query pages with hybrid retrieval and token budget control.
Updated 4 months ago (2026-05-23 20:27 UTC)
4
GPL 2.0
searxng-mcp
Search Browser Automation Web Scraping
TadMSTR
A
license
A
quality
A
maintenance
MCP server for private web search via self-hosted SearXNG with local reranking, full-page content fetching via Firecrawl, and optional Ollama-powered query expansion and summaries.
Updated 9 hours ago (2026-09-19 20:08 UTC)
7
109 npm
24
MIT
myscrape
Browser Automation Web Scraping Search
Bonifatius94
A
license
Not graded
quality
C
maintenance
A self-contained web-research MCP server that lets local LLM agents search, fetch, and synthesize web content using tools like web_search, web_fetch, and web_research.
Updated 24 days ago (2026-08-26 18:34 UTC)
2
MIT
websearch-mcp
Search RAG Systems Browser Automation
jason920612
A
license
Not graded
quality
C
maintenance
Semantic web search MCP server that navigates the live web using a cheap LLM and local embeddings, caching results for fast responses to similar queries without relying on general search engines.
Updated 2 months ago (2026-08-02 03:19 UTC)
MIT