Skip to main content
Glama
KylinMountain

web-fetch-mcp

by KylinMountain
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Web Fetch MCP Server

English | 中文 npm version

A Model Context Protocol (MCP) server that provides web content fetching, summarization, comparison, and extraction capabilities.

Features

  • Three Core Tools: Provides summarize_web, compare_web, and extract_web for versatile web content processing.

  • Handles Multiple URLs: Process up to 20 URLs in a single request.

  • Content Transformation: Converts HTML to clean, readable text and automatically resolves GitHub /blob/ URLs to their raw content equivalent.

  • Safe & Secure: Protects against Server-Side Request Forgery (SSRF) by blocking requests to private IP addresses.

  • Configurable: Allows setting timeouts and content length limits to manage performance.

Related MCP server: MCP Server Fetch Python

Installation

Install the server globally from npm:

npm install -g web-fetch-mcp

MCP Agent Configuration

To use this server with an AI agent that supports the Model Context Protocol, add the following configuration to your agent's settings. Once configured, your agent can call the tools provided by this service.

Important: You must provide a valid Gemini API key for the server to work.

If you installed the package globally:

{
  "mcpServers": {
    "web-fetch-mcp": {
      "type": "stdio",
      "command": "web-fetch-mcp",
      "env": {
        "GEMINI_API_KEY": "YOUR_GEMINI_API_KEY"
      }
    }
  }
}

Note: If you encounter network access issues (e.g., unable to connect to Gemini), you can configure the environment variables HTTPS_PROXY and HTTP_PROXY. By default, the gemini-2.5-flash model is used, consistent with Gemini-CLI.

If you are running from a local clone:

{
  "mcpServers": {
    "web-fetch-mcp": {
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/web-fetch-mcp/dist/index.js"],
      "env": {
        "GEMINI_API_KEY": "YOUR_GEMINI_API_KEY"
      }
    }
  }
}

Tool Reference

The service provides the following tools:

  • summarize_web: Summarizes content from one or more URLs.

  • compare_web: Compares content across multiple URLs.

  • extract_web: Extracts specific information from web content using natural language prompts.

Example Tool Call

To use a tool, your agent should make a callTool request specifying the tool name and a prompt:

{
  "tool": "summarize_web",
  "arguments": {
    "prompt": "Summarize the main points from https://example.com/article"
  }
}

For Developers

If you wish to contribute to the development of this server:

  1. Clone the repository:

    git clone https://github.com/your-username/web-fetch-mcp.git
cd web-fetch-mcp

  2. Install dependencies:

    npm install

  3. Run in development mode:

    npm run dev

  4. Build for production:

    npm run build

Available Tools

3 tools
compare_webB

Compare content from multiple URLs

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesNatural language prompt containing URLs (up to 20) and comparison instructions

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states the high-level action with no details on input limits, output format, error behavior, or whether multiple URLs are required as opposed to optional.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though it could be seen as under-specified in terms of what 'compare' entails.

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 tool with one parameter and no output schema, the description gives the essential purpose and the schema provides invocation details. However, it lacks usage context (e.g., what output to expect) and does not mention any constraints beyond what is in the schema.

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?

The schema description covers the single parameter well: 'Natural language prompt containing URLs (up to 20) and comparison instructions'. The tool description adds no additional parameter context, but since schema coverage is 100%, the baseline score of 3 applies.

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's purpose with a specific verb ('Compare') and resource ('content from multiple URLs'). It distinguishes itself from sibling tools (summarize_web, extract_web) by indicating a distinct action.

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 provides no guidance on when to use this tool versus alternatives. There is no mention of when comparison would be preferred over summarization or extraction, and no exclusion criteria are given.

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

extract_webC

Extract specific information from web content based on natural language prompts

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesNatural language prompt containing URLs (up to 20) and extraction instructions

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool uses natural language prompts, but does not mention any limitations, side effects, or operational constraints. The description is merely a functional statement with no transparency beyond that.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no redundant information. It is efficient and appropriately sized for a tool with one parameter, though it could have been slightly more informative without losing conciseness.

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?

There is no output schema, so the description should clarify what the tool returns, but it does not. No sibling tool context is provided, and no usage examples or limitations are mentioned. For a tool with minimal annotations and no output schema, the description is incomplete.

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?

The input schema fully documents the single 'prompt' parameter with a clear description (including URLs and extraction instructions), so schema coverage is 100%. The tool description itself adds no additional meaning beyond what the schema already provides, making the baseline of 3 appropriate.

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

Purpose4/5

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

The description clearly states the verb 'Extract' and resource 'web content', indicating a specific extraction action. It distinguishes from sibling tools by the nature of the operation (extract vs summarize/compare), though it does not explicitly name alternatives.

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 provided on when to use this tool versus alternatives like summarize_web or compare_web. The description only states what it does, without any contextual cues for usage decisions.

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

summarize_webC

Summarize content from one or more URLs

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesNatural language prompt containing URLs (up to 20) and summarization instructions

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the action without explaining how URLs are processed, what the summary output looks like, or any side effects or limitations beyond the schema's mention of up to 20 URLs.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no wasted words: 'Summarize content from one or more URLs.' It is appropriately brief, though the brevity does limit the contextual value it provides.

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?

Given one parameter and no output schema, the description is minimally adequate but leaves gaps: it does not describe the output format, usage distinctions from extract_web/compare_web, or behavioral caveats. The schema compensates for URL limits and prompt structure.

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?

The input schema has 100% coverage for the single prompt parameter, describing it as a natural language prompt containing URLs and summarization instructions. The tool description adds no parameter-level meaning beyond this, so baseline 3 applies.

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

Purpose4/5

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

The description clearly states the core action—summarize—and the resource—content from URLs. It is specific enough to distinguish from sibling tools like extract_web and compare_web, though it does not explicitly name those alternatives.

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?

There is no guidance on when to use this tool vs. alternatives, no prerequisites, and no exclusions. The description simply says what it does, leaving the agent to infer usage context from the tool name and schema.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.1
    • First observedcompare_web
    • First observedextract_web
    • First observedsummarize_web
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: summarize gives an overview, compare contrasts multiple URLs, and extract pulls specific details. No ambiguity between them.

Naming Consistency5/5

All tool names follow the same verb_web pattern (summarize_web, compare_web, extract_web), making the set predictable and easy to navigate.

Tool Count5/5

Three tools is appropriately scoped for a web-content analysis server. Each tool addresses a distinct need without unnecessary bloat.

Completeness4/5

The toolset covers the core operations of summarization, comparison, and extraction. A minor gap is the absence of a raw fetch tool, but the server's purpose is focused on processed output, so this is acceptable.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KylinMountain/web-fetch-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server