Skip to main content
Glama
praveenc

FetchV2 MCP Server

by praveenc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

FetchV2 MCP Server

PyPI version CI Python 3.11+ License: MIT

FetchV2 is a Model Context Protocol (MCP) server that retrieves web pages and returns clean Markdown. It uses Trafilatura to remove navigation, advertisements, footers, and other page elements.

What it does

Tool

Use

fetch

Fetch one web page and extract its main content

fetch_batch

Fetch up to 10 web pages in one request

discover_links

Find and filter links on a web page

fetch_llms_txt

Read an llms.txt index and optionally fetch its linked pages

FetchV2 can return raw HTML, preserve links and tables, and paginate long content. The fetch tool checks robots.txt by default.

Related MCP server: singlefile-mcp

Quick start

Requirements

  1. Install uv.

  2. Install Python 3.11 or newer:

uv python install 3.11

Install for Cursor or VS Code

Cursor

VS Code

Install MCP Server

Install on VS Code

Configure another MCP client

Add this server definition to your MCP client configuration:

{
  "mcpServers": {
    "fetchv2": {
      "command": "uvx",
      "args": ["fetchv2-mcp-server@latest"]
    }
  }
}

Common configuration file locations:

  • Claude Desktop on macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Claude Desktop on Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Windsurf: ~/.codeium/windsurf/mcp_config.json

  • Kiro: .kiro/settings/mcp.json in your project

Install in a Python environment

Use one of these commands if you want to install the package directly:

uv add fetchv2-mcp-server
pip install fetchv2-mcp-server

Try it

Ask your MCP client to perform a task such as:

  • "Fetch the documentation from <URL>."

  • "Find links on <docs URL> that contain tutorial."

  • "Read these pages and summarize their differences: [url1, url2, url3]."

Typical documentation workflow

First, find the relevant pages:

discover_links(url="https://docs.example.com/", filter_pattern="/guide/")

Then fetch the selected pages in one request:

fetch_batch(
    urls=[
        "https://docs.example.com/guide/intro",
        "https://docs.example.com/guide/setup",
    ]
)

Tool reference

fetch

Fetch one web page and extract its main content as Markdown.

fetch(
    url: str,
    max_length: int = 5000,
    start_index: int = 0,
    get_raw_html: bool = False,
    include_metadata: bool = True,
    include_tables: bool = True,
    include_links: bool = False,
    bypass_robots_txt: bool = False,
) -> str

Parameter

Type

Default

Description

url

str

required

Web page URL

max_length

int

5000

Maximum number of characters to return

start_index

int

0

Character offset for pagination

get_raw_html

bool

False

Return raw HTML without extraction

include_metadata

bool

True

Include the title, author, and date

include_tables

bool

True

Preserve tables in Markdown

include_links

bool

False

Preserve links in Markdown

bypass_robots_txt

bool

False

Skip the robots.txt check for a user-requested fetch

If the response is truncated, use the returned start_index value in the next call.

fetch_batch

Fetch up to 10 web pages and combine the results.

fetch_batch(
    urls: list[str],
    max_length_per_url: int = 2000,
    get_raw_html: bool = False,
) -> str

Parameter

Type

Default

Description

urls

list[str]

required

Web page URLs to fetch

max_length_per_url

int

2000

Maximum number of characters to return for each URL

get_raw_html

bool

False

Return raw HTML without extraction

This tool reports a failed URL in its result and continues with the other URLs. It does not check robots.txt.

discover_links

Find links on a web page and optionally filter them with a regular expression.

discover_links(url: str, filter_pattern: str = "") -> str

Parameter

Type

Default

Description

url

str

required

Web page URL to scan

filter_pattern

str

""

Regular expression used to filter links

The tool resolves relative links and returns up to 100 URLs.

fetch_llms_txt

Read an llms.txt file and list its documentation links.

fetch_llms_txt(
    url: str,
    include_content: bool = False,
    max_length_per_url: int = 2000,
) -> str

Parameter

Type

Default

Description

url

str

required

URL of an llms.txt file

include_content

bool

False

Fetch the content of all linked pages

max_length_per_url

int

2000

Maximum number of characters to return for each linked page

By default, this tool fetches only the llms.txt index. Set include_content=True to fetch all linked pages. This option can return a large response.

The tool resolves relative URLs, such as /docs/guide.md, against the llms.txt URL.

Prompts

  • fetch_manual creates a request to fetch and summarize one URL.

  • research_topic creates a request to research a topic with optional URLs.

Development

Clone the repository and install the development dependencies:

git clone https://github.com/praveenc/fetchv2-mcp-server.git
cd fetchv2-mcp-server
uv sync --dev

Run the tests:

uv run pytest

Run the server with MCP Inspector:

uv run mcp dev src/fetchv2_mcp_server/server.py

Run lint and type checks:

uv run ruff check .
uv run pyright

Contributing

Read CONTRIBUTING.md before you submit a change.

Support

Use the GitHub issue tracker to report a problem or request a feature.

License

This project uses the MIT License. See LICENSE for details.

Available Tools

4 tools
fetchA

Fetch a single webpage and extract its main content as clean markdown.

USE THIS TOOL WHEN:

  • You need to read an article, documentation page, or blog post

  • You want clean, readable text without boilerplate (navbars, ads, footers)

  • The user provides a specific URL to read

DO NOT USE WHEN:

  • You need to fetch multiple URLs (use fetch_batch instead - fewer round trips)

  • You want to discover what pages exist on a site (use discover_links first)

PAGINATION: Large pages are automatically truncated. The response will include 'use start_index=N to continue' - call again with that value to get more content.

EXAMPLES:

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe webpage URL to fetch (must be http:// or https://)
max_lengthNoMaximum characters to return. Use 1000-2000 for summaries, 5000 (default) for full content.
start_indexNoCharacter offset for pagination. Use the value from 'start_index=N' in truncated responses.
get_raw_htmlNoSkip extraction and return raw HTML. Use when you need original markup or extraction fails.
include_linksNoPreserve hyperlinks in markdown. Enable to follow references.
include_tablesNoPreserve tables in markdown. Disable for text-only articles.
include_metadataNoInclude title, author, date at top. Disable to save tokens.
bypass_robots_txtNoSkip robots.txt check. Only for user-initiated requests.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden and it does disclose key behaviors: boilerplate removal, automatic truncation, and pagination via start_index. It does not discuss robots.txt handling or failure modes, but those are partly covered by parameter schema.

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?

Well-structured with a clear purpose statement, explicit usage sections, a pagination note, and concise examples. Every section earns its place and the most important information is front-loaded.

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 an 8-parameter tool with an output schema, the description covers the core behavior, alternatives, pagination, and parameter usage. The output schema handles return values, so nothing essential is missing for correct invocation.

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 coverage is 100%, so the baseline is 3. The description adds practical meaning with examples showing max_length to save context and include_tables to preserve tabular data, plus pagination usage. This goes slightly beyond the raw schema.

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?

States a specific verb and resource: fetch a single webpage and extract main content as clean markdown. Clearly differentiates from fetch_batch and discover_links, so an agent can select it without opening the schema.

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 USE THIS WHEN and DO NOT USE WHEN sections, naming fetch_batch and discover_links as alternatives with reasons. This gives the agent unambiguous selection criteria.

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

fetch_batchA

Fetch multiple webpages in a single request and return combined content.

USE THIS TOOL WHEN:

  • You have 2-10 URLs to read (e.g., from discover_links results)

  • Comparing content across multiple pages

  • Gathering context from several documentation pages at once

KEY BENEFIT: One tool call instead of multiple fetch() calls = fewer round trips, faster results, and reduced overhead in supervised/approval workflows.

WORKFLOW EXAMPLE:

  1. discover_links(url="https://docs.example.com", filter_pattern="/api/")

  2. fetch_batch(urls=[...returned links...], max_length_per_url=1500)

NOTES:

  • Each URL's content is separated by '---' dividers

  • Failed URLs show inline errors without stopping other fetches

  • Robots.txt is NOT checked for batch fetches (assumes prior discovery)

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsYesList of webpage URLs to fetch (max 10). URLs are fetched sequentially and results combined.
get_raw_htmlNoSkip content extraction and return raw HTML for all URLs.
max_length_per_urlNoCharacter limit per URL. Use 1000-1500 when fetching many pages. Default 2000.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers: it discloses output formatting ('separated by '---' dividers'), error handling ('failed URLs show inline errors without stopping other fetches'), and policy caveat ('Robots.txt is NOT checked'). These are meaningful behavioral traits beyond the schema.

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 with clear sections (purpose, usage, benefit, workflow, notes) and front-loads the core purpose in the first sentence. Every section earns its place: the workflow example is actionable, and the notes disclose critical behavioral caveats.

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?

The description covers purpose, when-to-use, workflow, and behavioral notes. With a complete input schema and an output schema present, the description need not explain return values. It leaves no obvious gaps an agent would need to call the tool correctly.

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 adds only marginal parameter guidance via the workflow example (max_length_per_url=1500), but does not explain parameter semantics beyond what the schema already states. It meets but does not exceed the baseline.

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 begins with a clear, specific verb+resource statement: 'Fetch multiple webpages in a single request and return combined content.' It explicitly distinguishes this tool from siblings like fetch (single URL) and discover_links (link discovery), and the '2-10 URLs' condition further clarifies its scope.

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?

The description includes an explicit 'USE THIS TOOL WHEN' section with concrete conditions (2-10 URLs, comparing pages, gathering context), gives a workflow example linking discover_links to fetch_batch, and contrasts it with 'multiple fetch() calls'. This provides clear when-to-use guidance and implicitly identifies the alternative.

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

fetch_llms_txtA

Fetch and parse an llms.txt file to discover LLM-friendly documentation.

USE THIS TOOL WHEN:

  • A site provides an llms.txt file for AI-friendly content discovery

  • You need to understand what documentation is available

  • You want to fetch structured docs in a single request

WHAT IS llms.txt: A proposal for sites to provide LLM-friendly content at /llms.txt. It's a markdown file listing documentation links with descriptions. See https://llmstxt.org for the specification.

WORKFLOW:

  1. fetch_llms_txt(url="https://example.com/llms.txt") → Get structure

  2. Review sections and links

  3. Either use include_content=True or fetch_batch for specific pages

EXAMPLES:

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL to an llms.txt file (e.g., https://example.com/llms.txt)
include_contentNoIf true, also fetch content of all linked pages. Default false.
max_length_per_urlNoWhen include_content=True, max chars per linked page. Default 2000.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden, and it does a good job: it explains that the tool fetches and parses an llms.txt file, describes the optional include_content behavior, and provides a workflow. It doesn't cover error handling or auth, but for a read-only fetch tool with an output schema, the main behavioral traits are disclosed.

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 longer than average but well organized into purpose, usage, background, workflow, and examples. Each section adds useful context, and the key action is front-loaded. It could be slightly tighter, but the structure makes it easy to scan.

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 tool with an output schema and clear parameter documentation, the description covers the what, when, and how well, including examples and an alternative path via fetch_batch. It doesn't discuss failure scenarios or rate limits, but nothing essential for a correct first invocation is missing.

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 coverage is 100%, so the schema already documents all three parameters. The description adds value beyond the schema by providing real-world examples and showing how include_content=True is used in a workflow, which helps an agent understand parameter usage in context.

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 verb+resource pairing: 'Fetch and parse an llms.txt file to discover LLM-friendly documentation.' It clearly distinguishes this from sibling tools by focusing on the llms.txt format and even references fetch_batch in the workflow, so an agent can tell when this tool is the right one.

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?

The description includes a dedicated 'USE THIS TOOL WHEN' section listing concrete conditions, and the workflow explicitly names fetch_batch as the alternative for fetching specific pages. This gives an agent clear guidance on when to choose this tool over its siblings.

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. 4 tool updatesv2.0.0
    • First observeddiscover_links
    • First observedfetch
    • First observedfetch_batch
    • First observedfetch_llms_txt
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.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct retrieval mode: discover_links maps a site, fetch retrieves one URL, fetch_batch retrieves multiple URLs, and fetch_llms_txt parses the llms.txt format. Descriptions explicitly clarify when to use fetch vs fetch_batch, so an agent should not misselect.

Naming Consistency4/5

All tool names use a lowercase verb-first style: fetch, fetch_batch, fetch_llms_txt, discover_links. The only minor inconsistency is that plain 'fetch' lacks the object/scope qualifier the other names have, but the overall pattern remains predictable.

Tool Count5/5

Four tools is well-scoped for a web fetching and content discovery server. Each tool fills a distinct role—single fetch, batch fetch, link discovery, and llms.txt support—without unnecessary bloat or redundancy.

Completeness4/5

The server covers the core workflow end-to-end: discover relevant links, then fetch them individually or in batches. Minor gaps exist, such as no dedicated search or robots.txt checking tool, but these do not create dead ends for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • singlefile-mcp

    kwinsch
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server for intelligent web content extraction from JavaScript-heavy sites using single-file and trafilatura. It enables AI agents to fetch, render, and paginate through clean article content and metadata.
    19
    MIT

  • web-fetch-mcp

    bpzx
    A
    license
    A
    quality
    C
    maintenance
    MCP server for web page fetching (converting to Markdown/text with automatic fallback between Tavily and Firecrawl) and web search via Tavily.
    2
    MIT