Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mult-fetch-mcp-server fetch https://example.com and return 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.
This project implements an MCP-compliant client and server for communication between AI assistants and external tools.
fetch-mcp/
├── src/ # Source code directory
│ ├── lib/ # Library files
│ │ ├── fetchers/ # Web fetching implementation
│ │ │ ├── browser/ # Browser-based fetching
│ │ │ │ ├── BrowserFetcher.ts # Browser fetcher implementation
│ │ │ │ ├── BrowserInstance.ts # Browser instance management
│ │ │ │ └── PageOperations.ts # Page interaction operations
│ │ │ ├── node/ # Node.js-based fetching
│ │ │ └── common/ # Shared fetching utilities
│ │ ├── utils/ # Utility modules
│ │ │ ├── ChunkManager.ts # Content chunking
│ │ │ ├── ContentProcessor.ts # HTML to text conversion
│ │ │ ├── ContentExtractor.ts # Intelligent content extraction
│ │ │ ├── ContentSizeManager.ts # Content size limiting
│ │ │ └── ErrorHandler.ts # Error handling
│ │ ├── server/ # Server-related modules
│ │ │ ├── index.ts # Server entry
│ │ │ ├── browser.ts # Browser management
│ │ │ ├── fetcher.ts # Web fetching logic
│ │ │ ├── tools.ts # Tool registration and handling
│ │ │ ├── resources.ts # Resource handling
│ │ │ ├── prompts.ts # Prompt templates
│ │ │ └── types.ts # Server type definitions
│ │ ├── i18n/ # Internationalization support
│ │ └── types.ts # Common type definitions
│ ├── client.ts # MCP client implementation
│ └── mcp-server.ts # MCP server main entry
├── index.ts # Server entry point
├── tests/ # Test files
└── dist/ # Compiled filesRelated MCP server: Crawl4AI MCP Server
The Model Context Protocol (MCP) defines two main transport methods:
Standard Input/Output (Stdio): The client starts the MCP server as a child process, and they communicate through standard input (stdin) and standard output (stdout).
Server-Sent Events (SSE): Used to pass messages between client and server.
This project implements the Standard Input/Output (Stdio) transport method.
Implementation based on the official MCP SDK
Support for Standard Input/Output (Stdio) transport
Multiple web scraping methods (HTML, JSON, text, Markdown, plain text conversion)
Intelligent mode switching: automatic switching between standard requests and browser mode
Content size management: automatically splits large content into manageable chunks to solve AI model context size limitations
Chunked content retrieval: ability to request specific chunks of large content while maintaining context continuity
Detailed debug logging to stderr
Bilingual internationalization (English and Chinese)
Modular design for easy maintenance and extension
Intelligent Content Extraction: Based on Mozilla's Readability library, capable of extracting meaningful content from web pages while filtering out advertisements and navigation elements
Metadata Support: Ability to extract webpage metadata such as title, author, publication date, and site information
Smart Content Detection: Automatically detects if a page contains meaningful content, filtering out login pages, error pages, and other pages without substantial content
Browser Automation Enhancements: Support for page scrolling, cookie management, selector waiting, and other advanced browser interactions
To install Mult Fetch MCP Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @lmcc-dev/mult-fetch-mcp-server --client claudepnpm installpnpm add -g @lmcc-dev/mult-fetch-mcp-serverOr run directly with npx (no installation required):
npx @lmcc-dev/mult-fetch-mcp-serverTo integrate this tool with Claude desktop, you need to add server configuration:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
This method is the simplest, doesn't require specifying the full path, and is suitable for global installation or direct use with npx:
{
"mcpServers": {
"mult-fetch-mcp-server": {
"command": "npx",
"args": ["@lmcc-dev/mult-fetch-mcp-server"],
"env": {
"MCP_LANG": "en" // Set language to English, options: "zh" or "en"
}
}
}
}If you need to use a specific installation location, you can specify the full path:
{
"mcpServers": {
"mult-fetch-mcp-server": {
"command": "path-to/bin/node",
"args": ["path-to/@lmcc-dev/mult-fetch-mcp-server/dist/index.js"],
"env": {
"MCP_LANG": "en" // Set language to English, options: "zh" or "en"
}
}
}
}Please replace path-to/bin/node with the path to the Node.js executable on your system, and replace path-to/@lmcc-dev/mult-fetch-mcp-server with the actual path to this project.
Below is an example of using this tool in Claude desktop client:
The image shows how Claude can use the fetch tools to retrieve web content and process it according to your instructions.
After configuration, restart Claude desktop, and you can use the following tools in your conversation:
fetch_html: Get HTML content of a webpage
fetch_json: Get JSON data
fetch_txt: Get plain text content
fetch_markdown: Get Markdown formatted content
fetch_plaintext: Get plain text content converted from HTML (strips HTML tags)
pnpm run buildpnpm run server
# or
node dist/index.js
# if globally installed, you can run directly
@lmcc-dev/mult-fetch-mcp-server
# or use npx
npx @lmcc-dev/mult-fetch-mcp-serverNote: The following client.js functionality is provided for demonstration and testing purposes only. When used with Claude or other AI assistants, the MCP server is driven by the AI, which manages the chunking process automatically.
The project includes a command-line client for testing and development purposes:
pnpm run client <method> <params_json>
# example
pnpm run client fetch_html '{"url": "https://example.com", "debug": true}'When testing with the command-line client, you can use these parameters to demonstrate content chunking capabilities:
--all-chunks: Command line flag to automatically fetch all chunks in sequence (demonstration purpose only)
--max-chunks: Command line flag to limit the maximum number of chunks to fetch (optional, default is 10)
The client.js demo tool provides real-time output capabilities:
node dist/src/client.js fetch_html '{"url":"https://example.com", "startCursor": 0, "contentSizeLimit": 500}' --all-chunks --debugThe demo client will automatically fetch all chunks in sequence and display them immediately, showcasing how large content can be processed in real-time.
# Run MCP functionality tests
npm run test:mcp
# Run mini4k.com website tests
npm run test:mini4k
# Run direct client call tests
npm run test:directThis project supports Chinese and English bilingual internationalization. You can set the language using environment variables:
Set the MCP_LANG environment variable to control the language:
# Set to English
export MCP_LANG=en
npm run server
# Set to Chinese
export MCP_LANG=zh
npm run server
# Windows system
set MCP_LANG=zh
npm run serverUsing environment variables ensures that all related processes (including the MCP server) use the same language settings.
By default, the system will choose a language according to the following priority:
MCP_LANG environment variable
Operating system language (if it starts with "zh", use Chinese)
English (as the final fallback option)
This project follows the MCP protocol specification and does not output any logs by default to avoid interfering with JSON-RPC communication. Debug information is controlled through call parameters:
Set the debug: true parameter when calling a tool:
{
"url": "https://example.com",
"debug": true
}Debug messages are sent to the standard error stream (stderr) using the following format:
[MCP-SERVER] MCP server starting...
[CLIENT] Fetching URL: https://example.comWhen debug mode is enabled, all debug messages are also written to a log file located at:
~/.mult-fetch-mcp-server/debug.logThis log file can be accessed through the MCP resources API:
// Access the debug log file
const result = await client.readResource({ uri: "file:///logs/debug" });
console.log(result.contents[0].text);
// Clear the debug log file
const clearResult = await client.readResource({ uri: "file:///logs/clear" });
console.log(clearResult.contents[0].text);This tool supports various methods to configure proxy settings:
proxy ParameterThe most direct way is to specify the proxy in the request parameters:
{
"url": "https://example.com",
"proxy": "http://your-proxy-server:port",
"debug": true
}The tool will automatically detect and use proxy settings from standard environment variables:
# Set proxy environment variables
export HTTP_PROXY=http://your-proxy-server:port
export HTTPS_PROXY=http://your-proxy-server:port
# Run the server
npm run serverThe tool attempts to detect system proxy settings based on your operating system:
Windows: Reads proxy settings from environment variables using the set command
macOS/Linux: Reads proxy settings from environment variables using the env command
If you're having issues with proxy detection:
Use the debug: true parameter to see detailed logs about proxy detection
Explicitly specify the proxy using the proxy parameter
Ensure your proxy URL is in the correct format: http://host:port or https://host:port
For websites that require browser capabilities, set useBrowser: true to use browser mode
When using browser mode (useBrowser: true), the tool will:
First try to use the explicitly specified proxy (if provided)
Then try to use system proxy settings
Finally, proceed without a proxy if none is found
Browser mode is particularly useful for websites that implement anti-scraping measures or require JavaScript execution.
This project handles parameters in the following ways:
debug: Passed through call parameters, each request can individually control whether to enable debug output
MCP_LANG: Retrieved from environment variables, controls the language settings of the entire server
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';
import path from 'path';
import { fileURLToPath } from 'url';
// Get the directory path of the current file
const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);
// Create client transport layer
const transport = new StdioClientTransport({
command: 'node',
args: [path.resolve(__dirname, 'dist/index.js')],
stderr: 'inherit',
env: {
...process.env // Pass all environment variables, including MCP_LANG
}
});
// Create client
const client = new Client({
name: "example-client",
version: "1.0.0"
});
// Connect to transport layer
await client.connect(transport);
// Use client
const result = await client.callTool({
name: 'fetch_html',
arguments: {
url: 'https://example.com',
debug: true // Control debug output through parameters
}
});
if (result.isError) {
console.error('Fetch failed:', result.content[0].text);
} else {
console.log('Fetch successful!');
console.log('Content preview:', result.content[0].text.substring(0, 500));
}fetch_html: Get HTML content of a webpage
fetch_json: Get JSON data
fetch_txt: Get plain text content
fetch_markdown: Get Markdown formatted content
fetch_plaintext: Get plain text content converted from HTML (strips HTML tags)
The server includes support for the resources/list and resources/read methods, but currently no resources are defined in the implementation. The resource system is designed to provide access to project files and documentation, but this feature is not fully implemented yet.
// Example: List available resources
const resourcesResult = await client.listResources({});
console.log('Available resources:', resourcesResult);
// Note: Currently this will return empty lists for resources and resourceTemplatesThe server provides the following prompt templates:
fetch-website: Get website content, supporting different formats and browser mode
extract-content: Extract specific content from a website, supporting CSS selectors and data type specification
debug-fetch: Debug website fetching issues, analyze possible causes and provide solutions
Use prompts/list to get a list of available prompt templates
Use prompts/get to get specific prompt template content
// Example: List available prompt templates
const promptsResult = await client.listPrompts({});
console.log('Available prompts:', promptsResult);
// Example: Get website content prompt
const fetchPrompt = await client.getPrompt({
name: "fetch-website",
arguments: {
url: "https://example.com",
format: "html",
useBrowser: "false"
}
});
console.log('Fetch website prompt:', fetchPrompt);
// Example: Debug website fetching issues
const debugPrompt = await client.getPrompt({
name: "debug-fetch",
arguments: {
url: "https://example.com",
error: "Connection timeout"
}
});
console.log('Debug fetch prompt:', debugPrompt);Each tool supports the following parameters:
url: URL to fetch (required)
headers: Custom request headers (optional, default {})
proxy: Proxy server URL in the format http://host:port or https://host:port (optional)
timeout: Timeout in milliseconds (optional, default is 30000)
maxRedirects: Maximum number of redirects to follow (optional, default is 10)
noDelay: Whether to disable random delay between requests (optional, default is false)
useSystemProxy: Whether to use system proxy (optional, default is true)
enableContentSplitting: Whether to split large content into chunks (optional, default is true)
contentSizeLimit: Maximum content size in bytes before splitting (optional, default is 50000)
startCursor: Starting cursor position in bytes for retrieving content from a specific position (optional, default is 0)
These parameters help manage large content that would exceed AI model context size limits, allowing you to retrieve web content in manageable chunks while maintaining the ability to process the complete information.
chunkId: Unique identifier for a chunk set when content is split (used for requesting subsequent chunks)
When content is split into chunks, the response includes metadata that allows the AI to request subsequent chunks using the chunkId and startCursor parameters. The system uses byte-level chunk management to provide precise control over content retrieval, enabling seamless processing of content from any position.
useBrowser: Whether to use browser mode (optional, default is false)
useNodeFetch: Whether to force using Node.js mode (optional, default is false, mutually exclusive with useBrowser)
autoDetectMode: Whether to automatically detect and switch to browser mode if standard mode fails with 403/Forbidden errors (optional, default is true). Set to false to strictly use the specified mode without automatic switching.
waitForSelector: Selector to wait for in browser mode (optional, default is 'body')
waitForTimeout: Timeout to wait in browser mode in milliseconds (optional, default is 5000)
scrollToBottom: Whether to scroll to the bottom of the page in browser mode (optional, default is false)
saveCookies: Whether to save cookies in browser mode (optional, default is true)
closeBrowser: Whether to close the browser instance (optional, default is false)
extractContent: Whether to use the Readability algorithm to extract main content (optional, default false)
includeMetadata: Whether to include metadata in the extracted content (optional, default false, only works when extractContent is true)
fallbackToOriginal: Whether to fall back to the original content when extraction fails (optional, default true, only works when extractContent is true)
debug: Whether to enable debug output (optional, default false)
Use the content extraction feature to get the core content of a webpage, filtering out navigation bars, advertisements, sidebars, and other distracting elements:
{
"url": "https://example.com/article",
"extractContent": true,
"includeMetadata": true
}The extracted content will include the following metadata (if available):
Title
Byline (author)
Site name
Excerpt
Content length
Readability flag (isReaderable)
To extract only the meaningful content from an article webpage:
{
"url": "https://example.com/news/article",
"extractContent": true,
"includeMetadata": true
}For websites where content extraction might fail, you can use fallbackToOriginal to ensure you get some content:
{
"url": "https://example.com/complex-layout",
"extractContent": true,
"fallbackToOriginal": true
}To close the browser instance without performing any fetch operation:
{
"url": "about:blank",
"closeBrowser": true
}The proxy is determined in the following order:
Command line specified proxy
proxy parameter in the request
Environment variables (if useSystemProxy is true)
Git configuration (if useSystemProxy is true)
If proxy is set, useSystemProxy will be automatically set to false.
When debug: true is set, logs will be output to stderr with the following prefixes:
[MCP-SERVER]: Logs from the MCP server
[NODE-FETCH]: Logs from the Node.js fetcher
[BROWSER-FETCH]: Logs from the browser fetcher
[CLIENT]: Logs from the client
[TOOLS]: Logs from the tool implementation
[FETCHER]: Logs from the main fetcher interface
[CONTENT]: Logs related to content handling
[CONTENT-PROCESSOR]: Logs from the HTML content processor
[CONTENT-SIZE]: Logs related to content size management
[CHUNK-MANAGER]: Logs related to content chunking operations
[ERROR-HANDLER]: Logs related to error handling
[BROWSER-MANAGER]: Logs from the browser instance manager
[CONTENT-EXTRACTOR]: Logs from the content extractor
MIT
Updated by lmcc-dev
Fetch a website and return the content as HTML. Best practices: 1) Always set startCursor=0 for initial requests, and use the fetchedBytes value from previous response for subsequent requests to ensure content continuity. 2) Set contentSizeLimit between 20000-50000 for large pages. 3) When handling large content, use the chunking system by following the startCursor instructions in the system notes rather than increasing contentSizeLimit. 4) If content retrieval fails, you can retry using the same chunkId and startCursor, or adjust startCursor as needed but you must handle any resulting data duplication or gaps yourself. 5) Always explain to users when content is chunked and ask if they want to continue retrieving subsequent parts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the website to fetch | |
| startCursor | Yes | Starting cursor position in bytes. Set to 0 for initial requests, and use the value from previous responses for subsequent requests to resume content retrieval. | |
| headers | No | Optional headers to include in the request | |
| proxy | No | Optional proxy server to use (format: http://host:port or https://host:port) | |
| timeout | No | Optional timeout in milliseconds (default: 30000) | |
| maxRedirects | No | Optional maximum number of redirects to follow (default: 10) | |
| useSystemProxy | No | Optional flag to use system proxy environment variables (default: true) | |
| debug | No | Optional flag to enable detailed debug logging (default: false) | |
| noDelay | No | Optional flag to disable random delay between requests (default: false) | |
| useBrowser | No | Optional flag to use headless browser for fetching (default: false) | |
| waitForSelector | No | Optional CSS selector to wait for when using browser mode | |
| waitForTimeout | No | Optional timeout to wait after page load in browser mode (default: 5000) | |
| scrollToBottom | No | Optional flag to scroll to bottom of page in browser mode (default: false) | |
| closeBrowser | No | Optional flag to close the browser after fetching (default: false) | |
| saveCookies | No | Optional flag to save cookies for future requests to the same domain (default: true) | |
| autoDetectMode | No | Optional flag to automatically switch to browser mode if standard fetch fails (default: true). Set to false to strictly use the specified mode without automatic switching. | |
| contentSizeLimit | No | Optional maximum content size in bytes before splitting into chunks (default: 50KB). Set between 20KB-50KB for optimal results. For large content, prefer smaller values (20KB-30KB) to avoid truncation. | |
| enableContentSplitting | No | Optional flag to enable content splitting for large responses (default: true) | |
| chunkId | No | Optional chunk ID for retrieving a specific chunk of content from a previous request. The system adds prompts in the format === SYSTEM NOTE === ... =================== which AI models should ignore when processing the content. | |
| extractContent | No | Optional flag to enable intelligent content extraction using Readability algorithm (default: false). Extracts main article content from web pages. | |
| includeMetadata | No | Optional flag to include metadata (title, author, etc.) in the extracted content (default: false). Only works when extractContent is true. | |
| fallbackToOriginal | No | Optional flag to fall back to the original content when extraction fails (default: true). Only works when extractContent is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses chunking behavior, cursor management, retry semantics, data duplication risks, and instruction to ignore system notes. Comprehensive coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with five bullet-pointed best practices. Front-loaded with purpose, each sentence provides unique value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters and no output schema, the description covers core usage patterns well but could briefly mention response structure or error codes. Still highly informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by providing usage context for key parameters like startCursor (always set to 0) and contentSizeLimit (20-50KB), beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a website and return the content as HTML', specifying the verb, resource, and output format. This distinguishes it from siblings like fetch_json, fetch_markdown, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Five explicit best practices guide when and how to use the tool, including initial cursor setting, content size limits, chunking, retry handling, and user communication. No exclusions needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a JSON file from a URL. Best practices: 1) Always set startCursor=0 for initial requests, and use the fetchedBytes value from previous response for subsequent requests to ensure content continuity. 2) Set contentSizeLimit between 20000-50000 for large files. 3) When handling large content, use the chunking system by following the startCursor instructions in the system notes rather than increasing contentSizeLimit. 4) If content retrieval fails, you can retry using the same chunkId and startCursor, or adjust startCursor as needed but you must handle any resulting data duplication or gaps yourself. 5) Always explain to users when content is chunked and ask if they want to continue retrieving subsequent parts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the website to fetch | |
| startCursor | Yes | Starting cursor position in bytes. Set to 0 for initial requests, and use the value from previous responses for subsequent requests to resume content retrieval. | |
| headers | No | Optional headers to include in the request | |
| proxy | No | Optional proxy server to use (format: http://host:port or https://host:port) | |
| timeout | No | Optional timeout in milliseconds (default: 30000) | |
| maxRedirects | No | Optional maximum number of redirects to follow (default: 10) | |
| useSystemProxy | No | Optional flag to use system proxy environment variables (default: true) | |
| debug | No | Optional flag to enable detailed debug logging (default: false) | |
| noDelay | No | Optional flag to disable random delay between requests (default: false) | |
| useBrowser | No | Optional flag to use headless browser for fetching (default: false) | |
| waitForSelector | No | Optional CSS selector to wait for when using browser mode | |
| waitForTimeout | No | Optional timeout to wait after page load in browser mode (default: 5000) | |
| scrollToBottom | No | Optional flag to scroll to bottom of page in browser mode (default: false) | |
| closeBrowser | No | Optional flag to close the browser after fetching (default: false) | |
| saveCookies | No | Optional flag to save cookies for future requests to the same domain (default: true) | |
| autoDetectMode | No | Optional flag to automatically switch to browser mode if standard fetch fails (default: true). Set to false to strictly use the specified mode without automatic switching. | |
| contentSizeLimit | No | Optional maximum content size in bytes before splitting into chunks (default: 50KB). Set between 20KB-50KB for optimal results. For large content, prefer smaller values (20KB-30KB) to avoid truncation. | |
| enableContentSplitting | No | Optional flag to enable content splitting for large responses (default: true) | |
| chunkId | No | Optional chunk ID for retrieving a specific chunk of content from a previous request. The system adds prompts in the format === SYSTEM NOTE === ... =================== which AI models should ignore when processing the content. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job disclosing behavioral traits. It explains chunking, retry logic, data duplication handling, and even instructs the AI to communicate chunking to users.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but well-structured with numbered best practices. It front-loads the core purpose and then provides important detailed guidance. While not maximally concise, every sentence adds value given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 19 parameters, no output schema, and complex chunking behavior, the description covers initial requests, resumption, retries, and user communication. It lacks explicit error scenario details but is otherwise comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds significant semantic value by providing best practices for using startCursor and contentSizeLimit, explaining the chunking system, and offering guidance on parameter ranges (e.g., 20KB-50KB).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Fetch a JSON file from a URL' with a specific verb and resource type. The tool name and description clearly differentiate it from sibling tools (fetch_html, fetch_markdown, etc.) which handle other formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides best practices for using parameters like startCursor and contentSizeLimit, but does not explicitly state when to use this tool versus alternatives. Usage context is implied by the name and first sentence, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a website and return the content as Markdown. Best practices: 1) Always set startCursor=0 for initial requests, and use the fetchedBytes value from previous response for subsequent requests to ensure content continuity. 2) Set contentSizeLimit between 20000-50000 for large pages. 3) When handling large content, use the chunking system by following the startCursor instructions in the system notes rather than increasing contentSizeLimit. 4) If content retrieval fails, you can retry using the same chunkId and startCursor, or adjust startCursor as needed but you must handle any resulting data duplication or gaps yourself. 5) Always explain to users when content is chunked and ask if they want to continue retrieving subsequent parts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the website to fetch | |
| startCursor | Yes | Starting cursor position in bytes. Set to 0 for initial requests, and use the value from previous responses for subsequent requests to resume content retrieval. | |
| headers | No | Optional headers to include in the request | |
| proxy | No | Optional proxy server to use (format: http://host:port or https://host:port) | |
| timeout | No | Optional timeout in milliseconds (default: 30000) | |
| maxRedirects | No | Optional maximum number of redirects to follow (default: 10) | |
| useSystemProxy | No | Optional flag to use system proxy environment variables (default: true) | |
| debug | No | Optional flag to enable detailed debug logging (default: false) | |
| noDelay | No | Optional flag to disable random delay between requests (default: false) | |
| useBrowser | No | Optional flag to use headless browser for fetching (default: false) | |
| waitForSelector | No | Optional CSS selector to wait for when using browser mode | |
| waitForTimeout | No | Optional timeout to wait after page load in browser mode (default: 5000) | |
| scrollToBottom | No | Optional flag to scroll to bottom of page in browser mode (default: false) | |
| closeBrowser | No | Optional flag to close the browser after fetching (default: false) | |
| saveCookies | No | Optional flag to save cookies for future requests to the same domain (default: true) | |
| autoDetectMode | No | Optional flag to automatically switch to browser mode if standard fetch fails (default: true). Set to false to strictly use the specified mode without automatic switching. | |
| contentSizeLimit | No | Optional maximum content size in bytes before splitting into chunks (default: 50KB). Set between 20KB-50KB for optimal results. For large content, prefer smaller values (20KB-30KB) to avoid truncation. | |
| enableContentSplitting | No | Optional flag to enable content splitting for large responses (default: true) | |
| chunkId | No | Optional chunk ID for retrieving a specific chunk of content from a previous request. The system adds prompts in the format === SYSTEM NOTE === ... =================== which AI models should ignore when processing the content. | |
| extractContent | No | Optional flag to enable intelligent content extraction using Readability algorithm (default: false). Extracts main article content from web pages. | |
| includeMetadata | No | Optional flag to include metadata (title, author, etc.) in the extracted content (default: false). Only works when extractContent is true. | |
| fallbackToOriginal | No | Optional flag to fall back to the original content when extraction fails (default: true). Only works when extractContent is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses chunking behavior, retry implications (duplication/gaps), content splitting, browser mode usage, and system note prompts to ignore. This fully informs the agent of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but organized with a clear opening and numbered best practices. Each sentence serves a purpose, though it could be slightly more streamlined. Still, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, no output schema, and complex behavior (chunking, browser modes, retries), the description covers usage, limitations, and user interaction. It explains system notes and handles large content gracefully, making it sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The tool description adds value beyond schema by providing recommended ranges (e.g., contentSizeLimit 20000-50000), initial cursor guidance, and caveats about retries. Slight extra context elevates it above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a website and return the content as Markdown', specifying the verb (fetch), resource (website), and output format (Markdown). This distinguishes it from siblings like fetch_html (HTML), fetch_json (JSON), etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit best practices covering initial requests (startCursor=0), content size limits (20000-50000), chunking usage, retry handling with duplication warnings, and user communication about chunked content. It gives actionable guidance for when and how to use the tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a website and return the content as plain text with HTML tags removed. Best practices: 1) Always set startCursor=0 for initial requests, and use the fetchedBytes value from previous response for subsequent requests to ensure content continuity. 2) Set contentSizeLimit between 20000-50000 for large pages. 3) When handling large content, use the chunking system by following the startCursor instructions in the system notes rather than increasing contentSizeLimit. 4) If content retrieval fails, you can retry using the same chunkId and startCursor, or adjust startCursor as needed but you must handle any resulting data duplication or gaps yourself. 5) Always explain to users when content is chunked and ask if they want to continue retrieving subsequent parts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the website to fetch | |
| startCursor | Yes | Starting cursor position in bytes. Set to 0 for initial requests, and use the value from previous responses for subsequent requests to resume content retrieval. | |
| headers | No | Optional headers to include in the request | |
| proxy | No | Optional proxy server to use (format: http://host:port or https://host:port) | |
| timeout | No | Optional timeout in milliseconds (default: 30000) | |
| maxRedirects | No | Optional maximum number of redirects to follow (default: 10) | |
| useSystemProxy | No | Optional flag to use system proxy environment variables (default: true) | |
| debug | No | Optional flag to enable detailed debug logging (default: false) | |
| noDelay | No | Optional flag to disable random delay between requests (default: false) | |
| useBrowser | No | Optional flag to use headless browser for fetching (default: false) | |
| waitForSelector | No | Optional CSS selector to wait for when using browser mode | |
| waitForTimeout | No | Optional timeout to wait after page load in browser mode (default: 5000) | |
| scrollToBottom | No | Optional flag to scroll to bottom of page in browser mode (default: false) | |
| closeBrowser | No | Optional flag to close the browser after fetching (default: false) | |
| saveCookies | No | Optional flag to save cookies for future requests to the same domain (default: true) | |
| autoDetectMode | No | Optional flag to automatically switch to browser mode if standard fetch fails (default: true). Set to false to strictly use the specified mode without automatic switching. | |
| contentSizeLimit | No | Optional maximum content size in bytes before splitting into chunks (default: 50KB). Set between 20KB-50KB for optimal results. For large content, prefer smaller values (20KB-30KB) to avoid truncation. | |
| enableContentSplitting | No | Optional flag to enable content splitting for large responses (default: true) | |
| chunkId | No | Optional chunk ID for retrieving a specific chunk of content from a previous request. The system adds prompts in the format === SYSTEM NOTE === ... =================== which AI models should ignore when processing the content. | |
| extractContent | No | Optional flag to enable intelligent content extraction using Readability algorithm (default: false). Extracts main article content from web pages. | |
| includeMetadata | No | Optional flag to include metadata (title, author, etc.) in the extracted content (default: false). Only works when extractContent is true. | |
| fallbackToOriginal | No | Optional flag to fall back to the original content when extraction fails (default: true). Only works when extractContent is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses critical behaviors: chunking system, cursor-based pagination, retry implications (data duplication/gaps), content size limits, and handling of system prompts. This level of detail compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a numbered list and front-loaded purpose. Despite its length, each sentence adds value for a complex tool with 22 parameters. A slightly more condensed version could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 22 parameters, no output schema, and nested objects, the description is remarkably complete. It covers pagination, chunking, error handling, parameter ranges, and user communication. The lack of output schema is mitigated by explaining the return type (plain text).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema covers all parameters (100% coverage), the description adds significant context beyond syntax: recommended ranges (20000-50000 for contentSizeLimit), chunking workflow (startCursor/fetchedBytes/chunkId interplay), and parameter interactions (extractContent with includeMetadata/fallbackToOriginal).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a website and return the content as plain text with HTML tags removed', specifying the verb, resource, and output format. It distinguishes from sibling tools like fetch_html and fetch_json by emphasizing plain text output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive best practices for using startCursor, contentSizeLimit, chunking, and retry logic. However, it does not explicitly contrast with alternative tools (e.g., 'use fetch_html for HTML content'), leaving some implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a website, return the content as plain text (no HTML). Best practices: 1) Always set startCursor=0 for initial requests, and use the fetchedBytes value from previous response for subsequent requests to ensure content continuity. 2) Set contentSizeLimit between 20000-50000 for large pages. 3) When handling large content, use the chunking system by following the startCursor instructions in the system notes rather than increasing contentSizeLimit. 4) If content retrieval fails, you can retry using the same chunkId and startCursor, or adjust startCursor as needed but you must handle any resulting data duplication or gaps yourself. 5) Always explain to users when content is chunked and ask if they want to continue retrieving subsequent parts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the website to fetch | |
| startCursor | Yes | Starting cursor position in bytes. Set to 0 for initial requests, and use the value from previous responses for subsequent requests to resume content retrieval. | |
| headers | No | Optional headers to include in the request | |
| proxy | No | Optional proxy server to use (format: http://host:port or https://host:port) | |
| timeout | No | Optional timeout in milliseconds (default: 30000) | |
| maxRedirects | No | Optional maximum number of redirects to follow (default: 10) | |
| useSystemProxy | No | Optional flag to use system proxy environment variables (default: true) | |
| debug | No | Optional flag to enable detailed debug logging (default: false) | |
| noDelay | No | Optional flag to disable random delay between requests (default: false) | |
| useBrowser | No | Optional flag to use headless browser for fetching (default: false) | |
| waitForSelector | No | Optional CSS selector to wait for when using browser mode | |
| waitForTimeout | No | Optional timeout to wait after page load in browser mode (default: 5000) | |
| scrollToBottom | No | Optional flag to scroll to bottom of page in browser mode (default: false) | |
| closeBrowser | No | Optional flag to close the browser after fetching (default: false) | |
| saveCookies | No | Optional flag to save cookies for future requests to the same domain (default: true) | |
| autoDetectMode | No | Optional flag to automatically switch to browser mode if standard fetch fails (default: true). Set to false to strictly use the specified mode without automatic switching. | |
| contentSizeLimit | No | Optional maximum content size in bytes before splitting into chunks (default: 50KB). Set between 20KB-50KB for optimal results. For large content, prefer smaller values (20KB-30KB) to avoid truncation. | |
| enableContentSplitting | No | Optional flag to enable content splitting for large responses (default: true) | |
| chunkId | No | Optional chunk ID for retrieving a specific chunk of content from a previous request. The system adds prompts in the format === SYSTEM NOTE === ... =================== which AI models should ignore when processing the content. | |
| extractContent | No | Optional flag to enable intelligent content extraction using Readability algorithm (default: false). Extracts main article content from web pages. | |
| includeMetadata | No | Optional flag to include metadata (title, author, etc.) in the extracted content (default: false). Only works when extractContent is true. | |
| fallbackToOriginal | No | Optional flag to fall back to the original content when extraction fails (default: true). Only works when extractContent is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses chunking behavior, cursor-based retrieval, potential data duplication/gaps, and system note handling. However, it does not mention side effects, authentication needs, or rate limits, though these are likely minimal for a fetch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose, followed by well-organized numbered best practices. Despite length, every sentence adds value given the tool's complexity (22 params, chunking system). No redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core workflow and behavioral expectations thoroughly. However, lacks description of the output format/response structure (no output schema). Users would benefit from knowing what fields to expect (e.g., content, fetchedBytes, chunkId). Otherwise, complete for a fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline of 3. Description adds significant value with best practices for startCursor, contentSizeLimit, and chunking, going beyond schema definitions. It contextualizes how parameters work together for optimal use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Fetch' and resource 'website', and specifies output as 'plain text (no HTML)'. It distinguishes itself from siblings like fetch_html by emphasizing plain text. However, it could more explicitly differentiate from fetch_plaintext if that sibling exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides extensive best practices with numbered items covering initial cursor setup, chunk sizing, retry logic, and user communication. This gives clear guidance on when and how to use the tool effectively, including handling large content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_plaintext and fetch_txt have identical descriptions for plain text output, causing ambiguity. fetch_html, fetch_json, and fetch_markdown are distinct but the plain text tools overlap.
All tools follow a fetch_<format> pattern, but plaintext and txt are inconsistent: one uses full word, the other abbreviation.
5 tools is appropriate for a focused fetch server, covering common formats without being excessive.
Covers HTML, JSON, Markdown, and plain text, but the two plain text tools are redundant, wasting a slot that could add a different format like XML.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Zenrows MCP server — Fetch, Extract, Batch, and Browser Sessions for AI coding assistants
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Scrape, crawl and search the web for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lmcc-dev/mult-fetch-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
