Skip to main content
Glama
narimanamiri

MCP Web Fetch Server

by narimanamiri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

MCP Web Fetch Server

An all-in-one Python MCP server for web research: fetch pages, search the web, batch-fetch, extract links, summarize via client-side sampling, and (optionally) read/write local files — all for LLM agents like Cursor. Supports local stdio and Streamable HTTP for remote access, and exercises essentially every MCP protocol capability (Tools, Resources, Prompts, Completions, Sampling, Elicitation, Roots, Progress, Logging).

Documentation:

Document

What's inside

User Manual

Full end-user guide: install (Docker/Linux/Windows), Cursor setup, all tools, admin GUI, config, troubleshooting

Project Documentation

Full technical reference: architecture, modules, MCP APIs, admin API, security, Docker stack, testing

Features

Tools

  • fetch_url — page content as markdown, with chunked reading (start_index, max_length)

  • fetch_metadata_tool — HEAD request metadata

  • batch_fetch — fetch multiple URLs concurrently, with per-URL error isolation and progress

  • web_search — DuckDuckGo web search (no API key), with automatic fallback to a local SearXNG instance if DuckDuckGo's scrape fails

  • extract_links — structured link/image extraction from a page

  • summarize_url — asks the connected client's LLM to summarize a page (MCP sampling)

  • read_file / write_file / list_dir — sandboxed local file access (opt-in, disabled by default)

Other MCP capabilities

  • Resources: config://settings, history://recent, fetch-cache://{encoded_url}

  • Prompts: fetch, research_topic, summarize_page, extract_key_facts, compare_sources

  • Completions: URL/depth autocomplete for prompt and resource arguments

  • Elicitation: write_file confirms before overwriting an existing file

  • Roots: local file tools honor client-exposed directories in addition to FETCH_LOCAL_FILES_ROOT

  • Progress notifications: batch_fetch and summarize_url report progress as they run

  • Management GUI: web dashboard at /admin for status, config, history, cache, and tools

Security

  • SSRF protection with resolve-then-check and redirect re-validation

  • robots.txt compliance (override with ignore_robots_txt=true)

  • Optional domain allowlist

  • Local file tools sandboxed to one configured directory, path-traversal safe

  • Bearer token auth + rate limiting for HTTP mode

  • /health endpoint

  • Windows .exe build (no Python required for end users)

Related MCP server: myscrape

Quick Start

Option A: Docker — full stack (recommended for server deployment)

Runs the MCP server, admin GUI, and SearXNG together.

Linux / macOS:

cd mcp-fetch-server
cp .env.docker.example .env          # edit MCP_AUTH_TOKEN
chmod +x scripts/docker-up.sh
./scripts/docker-up.sh
# or: docker compose up -d --build

Windows (PowerShell):

cd "E:\my python projects\MCP\mcp-fetch-server"
copy .env.docker.example .env
.\scripts\docker-up.ps1

Service

URL

MCP protocol

http://127.0.0.1:8000/mcp

Admin GUI

http://127.0.0.1:8000/admin

Health

http://127.0.0.1:8000/health

SearXNG (search fallback)

http://127.0.0.1:8080

Connect Cursor over HTTP (Bearer token required):

{
  "mcpServers": {
    "web-fetch": {
      "url": "http://127.0.0.1:8000/mcp",
      "headers": { "Authorization": "Bearer your-token-from-env" }
    }
  }
}

Local files for read_file/write_file map to the ./workspace folder on your host.

Option B: Windows executable (local / Cursor stdio)

cd "E:\my python projects\MCP\mcp-fetch-server"
.\dist\mcp-fetch-server.exe --transport stdio

Build the exe yourself: .\scripts\build_exe.ps1 → outputs dist\mcp-fetch-server.exe

Option C: Python + uv (development)

cd "E:\my python projects\MCP\mcp-fetch-server"
uv sync --dev
copy .env.example .env
uv run mcp-fetch-server --transport stdio

Connect to Cursor

See the User Manual — Connect to Cursor for step-by-step instructions.

Minimal .cursor/mcp.json using the executable:

{
  "mcpServers": {
    "web-fetch": {
      "command": "E:/my python projects/MCP/mcp-fetch-server/dist/mcp-fetch-server.exe",
      "args": ["--transport", "stdio"],
      "env": { "PYTHONIOENCODING": "utf-8" }
    }
  }
}

Management GUI

A built-in web dashboard lets you monitor and manage the server without using Cursor:

Mode

URL

stdio (Cursor default)

http://127.0.0.1:8001/admin

streamable-http

http://127.0.0.1:8000/admin (same port as MCP)

The dashboard shows uptime, registered tools, redacted configuration, recent fetch history, cached page previews, and a button to clear history/cache. It auto-refreshes every 30 seconds.

If MCP_AUTH_TOKEN is set, enter it in the dashboard's auth bar (stored in your browser session only). Disable the GUI with FETCH_ADMIN_ENABLED=false.

Optional: SearXNG search fallback

web_search uses DuckDuckGo by default and falls back to SearXNG when that scrape fails. When you use Docker (docker compose up), SearXNG is started automatically and the MCP container is preconfigured to reach it at http://searxng:8080.

For local (non-Docker) use, you can still run only SearXNG:

docker compose up -d searxng

Set FETCH_SEARXNG_URL=http://localhost:8080 in .env. See searxng/settings.yml.

Remote HTTP Mode (without full Docker stack)

$env:MCP_AUTH_TOKEN = "your-long-random-token"
.\dist\mcp-fetch-server.exe --transport streamable-http --host 127.0.0.1 --port 8000

  • MCP endpoint: http://127.0.0.1:8000/mcp

  • Health check: http://127.0.0.1:8000/health

Project Structure

mcp-fetch-server/
├── dist/mcp-fetch-server.exe   # Windows executable
├── src/mcp_fetch_server/       # Source code (tools, resources, prompts, security, ...)
├── tests/                      # 84 pytest tests
├── docs/                       # User manual + technical docs
├── scripts/docker-up.sh        # Linux/macOS stack startup
├── scripts/docker-up.ps1       # Windows stack startup
├── docker-compose.yml          # Full stack: MCP server + SearXNG
├── .env.docker.example         # Environment template for Docker Compose
├── Dockerfile                  # MCP server image
├── workspace/                  # Host folder mounted for local file tools (Docker)
├── searxng/settings.yml        # SearXNG config (JSON API enabled)
├── src/mcp_fetch_server/admin.py  # Management web GUI
└── .cursor/mcp.json            # Cursor config

Development

uv run pytest
uv run ruff check .
./scripts/docker-up.sh          # Linux / macOS
docker compose down

Windows only:

.\scripts\build_exe.ps1
.\scripts\docker-up.ps1

License

MIT

Available Tools

9 tools
batch_fetchA
Read-only

Fetch up to 10 public URLs concurrently and return each page's content (or error) in one response.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsYes
max_lengthNo
ignore_robots_txtNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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

The description discloses concurrent execution, 10 URL limit, and read-only behavior (consistent with readOnlyHint annotation). It also mentions error handling per URL. Missing details on max_length truncation and robots.txt respect, but overall provides useful behavioral context.

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?

Single sentence of 15 words, front-loaded with key constraints. Every word is necessary and clear. No waste.

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?

The description covers core function and constraints but omits parameter effects (max_length, ignore_robots_txt). Given the output schema may define return format, the description is adequate for basic tool selection but not fully complete for invocation without parameter explanation.

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

Parameters1/5

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

With 0% schema description coverage, the description should explain parameter meaning, but it only mentions 'public URLs'. It does not describe max_length (content size limit) or ignore_robots_txt (robots.txt bypass). The agent cannot infer parameter semantics from the description.

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 tool fetches up to 10 public URLs concurrently and returns content or error per URL. This specifies verb, resource, limit, concurrency, and return type, differentiating it from siblings like fetch_url (single).

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 implies use for batch fetching multiple public URLs, contrasting with single fetch. However, it lacks explicit when-to-use guidance, exclusions (e.g., private URLs), or alternatives like web_search or fetch_metadata_tool.

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

fetch_metadata_toolA
Read-only

Return HTTP metadata for a URL using a HEAD request.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description adds limited behavioral context beyond specifying the HEAD request method. No mention of potential errors or HTTP status handling.

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?

Single sentence, front-loaded with the action ('Return'), no wasted words. Highly efficient.

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

Completeness4/5

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

For a simple tool with an output schema, the description is arguably sufficient. However, it lacks guidance on prerequisites (e.g., valid URL) and edge cases.

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

Parameters2/5

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

With 0% schema description coverage, the description fails to add any meaning to the 'url' parameter, such as format, constraints, or example. It only loosely mentions 'URL' in the description.

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 states specifically that it returns HTTP metadata using a HEAD request, clearly distinguishing it from sibling tools like fetch_url (full content) or summarize_url.

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

Usage Guidelines3/5

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

The description implies using this tool when only metadata is needed without downloading the body, but it does not explicitly state when to use or not use it, nor mention alternative tools.

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

fetch_urlA
Read-only

Fetch a public HTTP/HTTPS URL and return page content as markdown. Use start_index to read long pages in chunks.

ParametersJSON Schema
NameRequiredDescriptionDefault
rawNo
urlYes
max_lengthNo
start_indexNo
ignore_robots_txtNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the agent knows this is safe. The description adds that it returns markdown and can handle pagination with start_index. It does not contradict annotations. Some behavioral details like ignore_robots_txt implications are not explained, but overall adequate.

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 two sentences, front-loaded with the core function, and contains no fluff. Every sentence earns its place.

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

Completeness2/5

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

With 5 parameters, an output schema, and 0% schema description coverage, the description is too brief. It fails to explain most parameters (raw, max_length, ignore_robots_txt) and does not mention output format or behavior beyond chunking. The agent would need to infer or experiment.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. Only start_index is mentioned (for chunking). Other parameters (raw, max_length, ignore_robots_txt) are not explained, leaving the agent uncertain about their effects. This is a significant gap for a 5-parameter tool.

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), the resource (public HTTP/HTTPS URL), and the output (page content as markdown). It also mentions chunking with start_index, distinguishing it from siblings like summarize_url or batch_fetch.

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 provides guidance on using start_index for long pages. However, it does not explicitly tell when not to use this tool versus alternatives like batch_fetch or summarize_url, nor does it mention any prerequisites or limitations.

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

list_dirA
Read-only

List the contents of a directory within an allowed local directory. Leave path empty to list the root itself.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, indicating no side effects. The description adds value by clarifying the tool operates within allowed local directories and that an empty path lists the root. This provides behavioral context beyond the annotation.

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, front-loaded with purpose, then parameter detail. No redundant information. Every word earns its place.

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

Completeness4/5

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

Given a simple tool with one parameter, an output schema, and read-only annotation, the description covers the essential: purpose, scope, and parameter behavior. It does not elaborate on error handling or return format, but the output schema covers the latter.

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?

Schema has 0% coverage, so the description must compensate. It explains the single parameter 'path' meaning and behavior (empty defaults to root). This adds meaning beyond the schema's type and default values.

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 tool lists directory contents and specifies it operates within allowed local directories. The 'Leave path empty to list the root itself' adds further precision. This distinguishes it from siblings like read_file (file content) and fetch_url (remote URLs).

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?

No guidance is given on when to use this tool versus alternatives (e.g., read_file, write_file). The description does not mention prerequisites or contexts where the tool should or should not be used.

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

read_fileA
Read-only

Read a text file from an allowed local directory (configured via FETCH_LOCAL_FILES_ROOT, plus any directories the client exposes as roots). Path is relative to the allowed directory.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true. Description adds that path is relative and directories are allowed, but doesn't disclose file size limits, encoding, or error behavior. Adequate but not rich.

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 with no wasted words. Purpose and key constraint are front-loaded.

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

Completeness4/5

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

Tool has simple input and output schema. Description covers purpose and path constraint. With output schema existing, return type is handled there. Minor omission: no mention of allowed file types or size limits.

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?

Schema has 0% description coverage; description adds critical meaning: 'Path is relative to the allowed directory.' This compensates well, though lacks examples.

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?

Clearly states verb 'Read' and resource 'text file from allowed local directory'. Distinguishes from siblings like fetch_url and write_file by specifying local file reading.

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?

Describes when to use (reading text files from allowed directories) and context about configuration (FETCH_LOCAL_FILES_ROOT, client roots). Lacks explicit when-not-to-use or alternatives, but the context is clear enough.

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

summarize_urlA

Fetch a URL and ask the connected client's LLM (via MCP sampling) to summarize it. Requires a client that supports the sampling capability; otherwise use fetch_url and summarize the content yourself.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
focusNo
max_lengthNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the dependency on MCP sampling for summarization, which is a key behavioral trait. However, it omits details about error handling, authentication, or side effects beyond fetching.

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, front-loaded with action and purpose. No redundant or tangential information.

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

Completeness2/5

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

Despite having an output schema, the description does not leverage it to explain return values. It also lacks details on how optional parameters affect behavior, leaving users guessing about their function.

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

Parameters1/5

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

Schema coverage is 0% with no parameter descriptions. The description only mentions 'url' implicitly but does not explain 'focus' or 'max_length'. For a tool with 3 parameters, the description should compensate but fails to do so.

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 'summarize' with the resource 'URL'. It distinguishes from sibling tools like fetch_url and extract_links by specifying the summarization action via client sampling.

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

Usage Guidelines5/5

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

Provides explicit directive: requires client with sampling capability, and suggests fallback using fetch_url and manual summarization. This clearly differentiates from alternatives.

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

write_fileA
DestructiveIdempotent

Write text content to a file within an allowed local directory. If the file already exists and overwrite=false, the user will be asked to confirm before it is replaced.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
contentYes
overwriteNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already indicate destructive and idempotent behavior. The description adds that if overwrite=false and the file exists, the user will be asked to confirm, which is useful context beyond the annotation flags.

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, front-loaded with the core purpose, no wasted words.

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?

The description covers the basic operation and overwrite behavior, but lacks details on path format, content encoding, or error handling. Since an output schema exists, return values are not required, but more context on input constraints would be helpful.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate but only explains the overwrite parameter behavior. Path and content parameters lack any description of format, constraints, or examples.

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 tool writes text content to a file within an allowed local directory, using a specific verb and resource. This distinguishes it from siblings like read_file and list_dir.

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 explains when overwrite=false triggers user confirmation, but does not explicitly state when to use this tool versus alternatives like batch_fetch (which fetches from URLs). However, the context of writing local files is clear enough.

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. 9 tool updatesv0.1.0
    • First observedbatch_fetch
    • First observedextract_links
    • First observedfetch_metadata_tool
    • First observedfetch_url
    • First observedlist_dir
    • First observedread_file
    • First observedsummarize_url
    • First observedweb_search
    • First observedwrite_file
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 9 tools

Disambiguation5/5

Each tool has a distinct purpose: fetching URLs (single, batch, metadata, links, search, summarize) and local file operations (list, read, write). No overlap between tools.

Naming Consistency4/5

Most tools follow a verb_noun pattern in snake_case. The one minor inconsistency is 'fetch_metadata_tool' which includes an unnecessary 'tool' suffix, but otherwise naming is consistent.

Tool Count5/5

9 tools is appropriate for a web fetch server that also includes local file capabilities. Not too many, not too few.

Completeness4/5

Web fetching covers single, batch, metadata, links, search, and summarize. Local file ops cover list, read, write but lack a delete tool. Minor gap.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • myscrape

    Bonifatius94
    A
    license
    Not graded
    quality
    A
    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.
    1
    MIT

  • url-context-mcp

    SkillfulElectro
    A
    license
    A
    quality
    B
    maintenance
    An MCP server that fetches web pages and extracts clean, AI-usable context from them, enabling tools for link discovery, content search, and integrated fetch-and-search operations.
    5
    15
    1
    MIT

  • free-web-search-mcp

    adi-santoso
    A
    license
    A
    quality
    C
    maintenance
    This MCP server enables free web search and page content extraction using real browsers, with support for multiple search engines and stealth browser backends. It provides tools for searching, fetching pages, and setting up the Camoufox stealth browser.
    3
    MIT