What can you do with this server?

The Fetch MCP Server allows you to fetch web content in various formats and apply transformations: * Fetch HTML: Retrieve raw HTML content from a webpage * Fetch JSON: Fetch and parse JSON content from a URL * Fetch Plain Text: Extract text content from webpages without HTML tags, scripts, or styles * Fetch Markdown: Convert and retrieve webpage content in Markdown format * Custom Headers: Add optional headers to requests for additional customization

Which integrations are available for this server?

Allows converting web content to Markdown format using the fetch_markdown tool, using TurndownService for HTML to Markdown conversion

How do I use Fetch MCP Server?

1. Click on "Install 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., "@Fetch MCP Server fetch the latest blog post from techcrunch.com as markdown" 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

Fetch MCP Server

by zcaceres

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Fetch MCP Server

fetch mcp logo

npm version

An MCP server for fetching web content in multiple formats — HTML, JSON, plain text, Markdown, readable article content, and YouTube transcripts.

Tools

All tools accept the following common parameters:

Parameter	Type	Required	Description
`url`	string	Yes	URL to fetch
`headers`	object	No	Custom headers to include in the request
`max_length`	number	No	Maximum characters to return (default: 5000)
`start_index`	number	No	Start from this character index (default: 0)
`proxy`	string	No	Proxy URL (e.g. `http://proxy:8080`)

fetch_html — Fetch a website and return its raw HTML content.
fetch_markdown — Fetch a website and return its content converted to Markdown.
fetch_txt — Fetch a website and return plain text with HTML tags, scripts, and styles removed.
fetch_json — Fetch a URL and return the JSON response.
fetch_readable — Fetch a website and extract the main article content using Mozilla Readability, returned as Markdown. Strips navigation, ads, and boilerplate. Ideal for articles and blog posts.
fetch_youtube_transcript — Fetch a YouTube video's captions/transcript. Uses yt-dlp if available, otherwise extracts directly from the page. Accepts an additional lang parameter (default: "en") to select the caption language.

Related MCP server: Fetch MCP Server

Installation

As an MCP server

Add to your MCP client configuration:

{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["mcp-fetch-server"]
    }
  }
}

As a CLI

npx mcp-fetch <command> <url> [flags]

Or install globally:

npm install -g mcp-fetch-server
mcp-fetch <command> <url> [flags]

CLI Usage

mcp-fetch <command> <url> [flags]

Commands

Command	Description
`html`	Fetch a URL and return raw HTML
`markdown`	Fetch a URL and return Markdown
`readable`	Fetch a URL and return article content as Markdown (via Readability)
`txt`	Fetch a URL and return plain text
`json`	Fetch a URL and return JSON
`youtube`	Fetch a YouTube video transcript

Flags

Flag	Description
`--max-length <N>`	Maximum characters to return
`--start-index <N>`	Start from this character index
`--proxy <URL>`	Proxy URL
`--lang <code>`	Language code for YouTube transcripts (default: `en`)
`--help`	Show help message
`--version`	Show version

Examples

# Fetch a page as markdown
mcp-fetch markdown https://example.com

# Extract article content without boilerplate
mcp-fetch readable https://example.com/blog/post

# Get a YouTube transcript in Spanish
mcp-fetch youtube https://www.youtube.com/watch?v=dQw4w9WgXcQ --lang es

# Fetch with a length limit
mcp-fetch html https://example.com --max-length 10000

# Fetch through a proxy
mcp-fetch json https://api.example.com/data --proxy http://proxy:8080

Environment Variables

Variable	Description
`DEFAULT_LIMIT`	Default character limit for responses (default: `5000`, set to `0` for no limit)
`MAX_RESPONSE_BYTES`	Maximum response body size in bytes (default: `10485760` / 10 MB)

Example with a custom limit:

{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["mcp-fetch-server"],
      "env": {
        "DEFAULT_LIMIT": "50000"
      }
    }
  }
}

Features

Fetch web content as HTML, JSON, plain text, or Markdown
Extract article content with Mozilla Readability (strips ads, nav, boilerplate)
Extract YouTube video transcripts (via yt-dlp or direct extraction)
Proxy support for requests behind firewalls
Pagination with max_length and start_index
Custom request headers
SSRF protection (blocks private/localhost addresses and DNS rebinding)
Response size limits to prevent memory exhaustion

Development

bun install
bun run dev     # start with watch mode
bun test        # run tests
bun run build   # build for production

License

This project is licensed under the MIT License.

Available Tools

4 tools

fetch_htmlC

Fetch a website and return its unmodified contents as HTML

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL of the website to fetch
`headers`	No	Optional headers to include in the request
`max_length`	No	Maximum number of characters to return (default: 5000)
`start_index`	No	Start content from this character index (default: 0)

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 mentions that content is 'unmodified' and returned 'as HTML', which is helpful, but lacks critical details like error handling, timeout behavior, authentication needs, rate limits, or whether it follows redirects. For a fetch operation with potential network issues, this is a significant gap.

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, efficient sentence that front-loads the core functionality ('fetch a website') and specifies the output ('unmodified contents as HTML'). Every word earns its place with zero waste or redundancy.

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?

Given the tool's complexity (network operation with 4 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't address error cases, performance characteristics, or what happens with malformed HTML. For a fetch tool that could encounter various real-world issues, more context is needed.

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 the schema already documents all parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema (e.g., it doesn't explain how 'max_length' interacts with HTML structure or whether 'headers' can override defaults). Baseline 3 is appropriate when the schema does the heavy lifting.

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 tool's purpose with a specific verb ('fetch') and resource ('website'), and indicates the output format ('HTML'). It distinguishes from sibling tools by specifying 'unmodified contents as HTML' rather than JSON, markdown, or text formats. However, it doesn't explicitly contrast with siblings beyond the output format.

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 like fetch_json, fetch_markdown, or fetch_txt. It doesn't mention scenarios where HTML output is preferred over other formats, nor does it discuss any prerequisites or constraints for usage.

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

fetch_jsonC

Fetch a JSON file from a URL

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL of the JSON to fetch
`headers`	No	Optional headers to include in the request
`max_length`	No	Maximum number of characters to return (default: 5000)
`start_index`	No	Start content from this character index (default: 0)

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 states the basic action but omits critical details such as error handling (e.g., for invalid URLs or non-JSON responses), authentication needs, rate limits, or whether it performs safe read operations. This leaves significant gaps in understanding the tool's 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, direct sentence that efficiently conveys the core purpose without any wasted words. It is front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.

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?

Given the tool's moderate complexity (4 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on return values, error cases, or behavioral traits, which are essential for an agent to use the tool effectively in varied contexts.

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% description coverage, clearly documenting all four parameters (url, headers, max_length, start_index). The description adds no additional meaning beyond what the schema provides, such as examples or usage notes, so it meets the baseline for adequate but unenhanced parameter semantics.

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 action ('Fetch') and resource ('a JSON file from a URL'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like fetch_html or fetch_markdown, which likely perform similar operations on different file types, so it misses full sibling distinction.

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 like fetch_html or fetch_markdown. It lacks any mention of prerequisites, exclusions, or specific contexts, leaving the agent to infer usage based on the tool name alone.

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

fetch_markdownC

Fetch a website and return its contents converted content to Markdown

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL of the website to fetch
`headers`	No	Optional headers to include in the request
`max_length`	No	Maximum number of characters to return (default: 5000})
`start_index`	No	Start content from this character index (default: 0)

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 states the tool fetches and converts content, but lacks details on error handling, rate limits, authentication needs, or what happens with invalid URLs. For a web-fetching tool with zero annotation coverage, this is a significant gap in transparency.

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, efficient sentence: 'Fetch a website and return its contents converted content to Markdown.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity.

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?

Given the tool's complexity (web fetching with conversion), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error cases, performance, or output format details. For a tool that interacts with external resources and transforms data, more context is needed.

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 the schema fully documents all four parameters (url, headers, max_length, start_index). The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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 tool's purpose: 'Fetch a website and return its contents converted content to Markdown.' It specifies the verb ('fetch'), resource ('website'), and transformation ('converted to Markdown'). However, it doesn't explicitly differentiate from sibling tools like fetch_html, fetch_json, and fetch_txt, which presumably return different formats.

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. It doesn't mention sibling tools or contexts where Markdown output is preferred over HTML, JSON, or plain text. Usage is implied by the tool's name and purpose, but no explicit when/when-not instructions are given.

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

fetch_txtA

Fetch a website, convert the content to plain text (no HTML)

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL of the website to fetch
`headers`	No	Optional headers to include in the request
`max_length`	No	Maximum number of characters to return (default: 5000)
`start_index`	No	Start content from this character index (default: 0)

TDQS

A3.7/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 mentions fetching and conversion but lacks details on error handling, rate limits, authentication needs, or what happens with invalid URLs. For a tool with no annotations, this leaves significant behavioral gaps.

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, efficient sentence that front-loads the core functionality with zero wasted words, making it easy to understand quickly.

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 no annotations and no output schema, the description covers the basic purpose but lacks details on return values, error cases, or operational constraints. It is minimally adequate but has clear gaps for a tool that interacts with external websites.

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 the schema fully documents all parameters. The description does not add any parameter-specific details beyond what the schema provides, such as examples or usage tips, meeting the baseline for high schema coverage.

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 specific action ('fetch a website') and transformation ('convert the content to plain text (no HTML)'), distinguishing it from sibling tools like fetch_html, fetch_json, and fetch_markdown which handle different output formats.

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 implicitly suggests usage for extracting plain text from websites, but does not explicitly state when to use this tool versus alternatives like fetch_html for raw HTML or fetch_markdown for markdown conversion. It provides clear context but lacks explicit exclusions or named alternatives.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: fetch_html returns raw HTML, fetch_json retrieves JSON files, fetch_markdown converts to Markdown, and fetch_txt extracts plain text. There is no ambiguity or overlap in functionality, making it easy for an agent to select the correct tool based on the desired output format.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'fetch_' prefix and descriptive suffixes (html, json, markdown, txt). This predictable naming scheme enhances readability and usability, allowing agents to intuitively understand each tool's function without confusion.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of fetching and converting web content. Each tool earns its place by covering distinct output formats (HTML, JSON, Markdown, plain text), avoiding bloat while providing comprehensive coverage for common web data retrieval needs.

Completeness5/5

The tool set provides complete coverage for the domain of fetching web content in various formats. It includes raw HTML, structured JSON, and converted formats (Markdown and plain text), leaving no obvious gaps. Agents can handle a wide range of web data retrieval scenarios without dead ends.

Maintenance

ActivityInactive

ResponsivenessWithin a week

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

webscrape-mcp
io.github.carrasquelalex1
Fetch any URL and get clean Markdown. Web scraping for AI agents.
Web Scraping Browser Automation
21
fetchgate A
dev.fetchgate
Fetch any URL as clean Markdown or metadata, and buy digital goods via x402 — for AI agents.
Browser Automation Payments & Billing
61
Brainiall Web A
com.brainiall
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Browser Automation Web Scraping
51
screenshot A
com.apiscreenshot
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Browser Automation Image & Video Processing
2

Related MCP Servers

Fetch MCP Server
Web Scraping Browser Automation Search
tokenizin
A
license
A
quality
D
maintenance
Provides functionality to fetch web content in various formats, including HTML, JSON, plain text, and Markdown.
Updated 2 years ago (2024-12-19 23:30 UTC)
4
102,856
2
MIT
Fetch MCP Server
Browser Automation Web Scraping
goswamig
A
license
B
quality
D
maintenance
Provides functionality to fetch web content in various formats, including HTML, JSON, plain text, and Markdown with support for custom headers.
Updated a year ago (2025-03-15 19:02 UTC)
4
102,856
3
MIT
Fetch MCP Server
Web Scraping Browser Automation
phpmac
A
license
Not graded
quality
C
maintenance
Provides functionality to fetch and transform web content in various formats (HTML, JSON, plain text, and Markdown) through simple API calls.
Updated a year ago (2025-07-29 20:06 UTC)
102,856
1
MIT
Fetch MCP Server
Browser Automation Web Scraping Search
SolonaBot
A
license
Not graded
quality
D
maintenance
Enables fetching and converting web content into various formats including HTML, JSON, plain text, and Markdown. It supports custom request headers and provides specialized tools for on-demand web data retrieval and transformation.
Updated 7 months ago (2026-02-09 04:29 UTC)
102,856
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/zcaceres/fetch-mcp'

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