en es ja ko zh

URL Fetch MCP

Name: URL Fetch MCP
Author: aelaguiz

by aelaguiz

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

URL 获取 MCP

一个干净的模型上下文协议 (MCP) 实现，使 Claude 或任何 LLM 能够从 URL 获取内容。

特征

从任意 URL 获取内容
支持多种内容类型（HTML、JSON、文本、图像）
控制请求参数（标头、超时）
清晰的错误处理
可与 Claude Code 和 Claude Desktop 配合使用

Related MCP server: @kazuph/mcp-fetch

存储库结构

url-fetch-mcp/
├── examples/               # Example scripts and usage demos
├── scripts/                # Helper scripts (installation, etc.)
├── src/
│   └── url_fetch_mcp/      # Main package code
│       ├── __init__.py
│       ├── __main__.py
│       ├── cli.py          # Command-line interface
│       ├── fetch.py        # URL fetching utilities
│       ├── main.py         # Core MCP server implementation
│       └── utils.py        # Helper utilities
├── LICENSE
├── pyproject.toml          # Project configuration
├── README.md
└── url_fetcher.py          # Standalone launcher for Claude Desktop

安装

# Install from source
pip install -e .

# Install with development dependencies
pip install -e ".[dev]"

用法

运行服务器

# Run with stdio transport (for Claude Code)
python -m url_fetch_mcp run

# Run with HTTP+SSE transport (for remote connections)
python -m url_fetch_mcp run --transport sse --port 8000

在 Claude Desktop 中安装

在Claude Desktop中有三种安装方式：

方法一：直接安装

# Install the package
pip install -e .

# Install in Claude Desktop using the included script
mcp install url_fetcher.py -n "URL Fetcher"

url_fetcher.py文件包含：

#!/usr/bin/env python
"""
URL Fetcher MCP Server

This is a standalone script for launching the URL Fetch MCP server.
It's used for installing in Claude Desktop with the command:
    mcp install url_fetcher.py -n "URL Fetcher"
"""

from url_fetch_mcp.main import app

if __name__ == "__main__":
    app.run()

方法 2：使用安装程序脚本

# Install the package
pip install -e .

# Run the installer script
python scripts/install_desktop.py

scripts/install_desktop.py脚本：

#!/usr/bin/env python
import os
import sys
import tempfile
import subprocess

def install_desktop():
    """Install URL Fetch MCP in Claude Desktop."""
    print("Installing URL Fetch MCP in Claude Desktop...")
    
    # Create a temporary Python file that imports our module
    temp_dir = tempfile.mkdtemp()
    temp_file = os.path.join(temp_dir, "url_fetcher.py")
    
    with open(temp_file, "w") as f:
        f.write("""#!/usr/bin/env python
# URL Fetcher MCP Server
from url_fetch_mcp.main import app

if __name__ == "__main__":
    app.run()
""")
    
    # Make the file executable
    os.chmod(temp_file, 0o755)
    
    # Run the mcp install command with the file path
    try:
        cmd = ["mcp", "install", temp_file, "-n", "URL Fetcher"]
        print(f"Running: {' '.join(cmd)}")
        
        result = subprocess.run(cmd, check=True, text=True)
        print("Installation successful!")
        print("You can now use the URL Fetcher tool in Claude Desktop.")
        return 0
    except subprocess.CalledProcessError as e:
        print(f"Error during installation: {str(e)}")
        return 1
    finally:
        # Clean up temporary file
        try:
            os.unlink(temp_file)
            os.rmdir(temp_dir)
        except:
            pass

if __name__ == "__main__":
    sys.exit(install_desktop())

方法 3：使用 CLI 命令

# Install the package
pip install -e .

# Install using the built-in CLI command
python -m url_fetch_mcp install-desktop

核心实现

MCP 的主要实现位于src/url_fetch_mcp/main.py中：

from typing import Annotated, Dict, Optional
import base64
import json
import httpx
from pydantic import AnyUrl, Field
from mcp.server.fastmcp import FastMCP, Context

# Create the MCP server
app = FastMCP(
    name="URL Fetcher",
    version="0.1.0",
    description="A clean MCP implementation for fetching content from URLs",
)

@app.tool()
async def fetch_url(
    url: Annotated[AnyUrl, Field(description="The URL to fetch")],
    headers: Annotated[
        Optional[Dict[str, str]], Field(description="Additional headers to send with the request")
    ] = None,
    timeout: Annotated[int, Field(description="Request timeout in seconds")] = 10,
    ctx: Context = None,
) -> str:
    """Fetch content from a URL and return it as text."""
    # Implementation details...

@app.tool()
async def fetch_image(
    url: Annotated[AnyUrl, Field(description="The URL to fetch the image from")],
    timeout: Annotated[int, Field(description="Request timeout in seconds")] = 10,
    ctx: Context = None,
) -> Dict:
    """Fetch an image from a URL and return it as an image."""
    # Implementation details...

@app.tool()
async def fetch_json(
    url: Annotated[AnyUrl, Field(description="The URL to fetch JSON from")],
    headers: Annotated[
        Optional[Dict[str, str]], Field(description="Additional headers to send with the request")
    ] = None,
    timeout: Annotated[int, Field(description="Request timeout in seconds")] = 10,
    ctx: Context = None,
) -> str:
    """Fetch JSON from a URL, parse it, and return it formatted."""
    # Implementation details...

工具功能

fetch_url

从 URL 获取内容并将其作为文本返回。

参数：

url （必填）：要获取的 URL
headers （可选）：与请求一起发送的附加标头
timeout （可选）：请求超时（秒）（默认值：10）

获取图像

从 URL 获取图像并将其作为图像返回。

参数：

url （必需）：获取图像的 URL
timeout （可选）：请求超时（秒）（默认值：10）

fetch_json

从 URL 获取 JSON，解析它，并返回格式化的 JSON。

参数：

url （必需）：从中获取 JSON 的 URL
headers （可选）：与请求一起发送的附加标头
timeout （可选）：请求超时（秒）（默认值：10）

示例

examples目录包含示例脚本：

quick_test.py ：MCP 服务器的快速测试
simple_usage.py ：使用客户端 API 的示例
interactive_client.py ：用于测试的交互式 CLI

# Example of fetching a URL
result = await session.call_tool("fetch_url", {
    "url": "https://example.com"
})

# Example of fetching JSON data
result = await session.call_tool("fetch_json", {
    "url": "https://api.example.com/data",
    "headers": {"Authorization": "Bearer token"}
})

# Example of fetching an image
result = await session.call_tool("fetch_image", {
    "url": "https://example.com/image.jpg"
})

测试

测试基本功能：

# Run a direct test of URL fetching
python direct_test.py

# Run a simplified test with the MCP server
python examples/quick_test.py

执照

麻省理工学院

Available Tools

3 tools

fetch_imageC

Fetch an image from a URL and return it as an image.

This tool allows Claude to retrieve images from any accessible web URL.
The image is returned in a format that Claude can display.

ParametersJSON Schema

Name	Required	Description	Default
`timeout`	No	Request timeout in seconds
`url`	Yes	The URL to fetch the image from

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 full burden. It mentions the tool fetches from 'any accessible web URL' and returns in a 'format that Claude can display,' but lacks details on error handling, authentication needs, rate limits, or what 'accessible' entails. For a network tool with zero annotation coverage, this is insufficient.

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 concise and well-structured with two sentences that directly address purpose and usage. It avoids redundancy and is front-loaded with the core functionality. However, the second sentence could be slightly more informative.

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 the tool has an output schema (which handles return values) and high schema coverage, the description is minimally adequate. However, for a network-based tool with no annotations, it should provide more behavioral context like error cases or accessibility constraints to be fully complete.

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 both parameters (url and timeout). The description adds no additional parameter semantics beyond what the schema provides, such as URL format constraints or timeout implications. Baseline 3 is appropriate when 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 an image from a URL and return it as an image.' It specifies the verb (fetch), resource (image), and outcome (return as image). However, it doesn't explicitly differentiate from sibling tools like fetch_json and fetch_url, which likely handle different data types.

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 minimal usage guidance: 'This tool allows Claude to retrieve images from any accessible web URL.' It implies use for image retrieval but offers no explicit when-to-use vs. alternatives, no prerequisites, and no mention of sibling tools for comparison.

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

fetch_jsonA

Fetch JSON from a URL, parse it, and return it formatted.

This tool allows Claude to retrieve and parse JSON data from any accessible web URL.
The JSON is prettified for better readability.

ParametersJSON Schema

Name	Required	Description
`headers`	No	Additional headers to send with the request
`timeout`	No	Request timeout in seconds
`url`	Yes	The URL to fetch JSON from

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses key behaviors: fetching from URLs, parsing JSON, and formatting output. However, it doesn't mention error handling, authentication needs, rate limits, or what happens with non-JSON responses. The description adds basic context but lacks comprehensive behavioral disclosure.

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 perfectly concise with two focused sentences that each earn their place. The first sentence states the core functionality, and the second provides additional context about accessibility and formatting. No wasted words, well-structured, and front-loaded with the main purpose.

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

Completeness4/5

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

Given the tool's moderate complexity (HTTP request with JSON parsing), no annotations, but 100% schema coverage and an output schema exists, the description is reasonably complete. It covers the main purpose and formatting behavior, though additional context about error cases or authentication would improve completeness for a tool making external requests.

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 three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'any accessible web URL' which reinforces the url parameter but doesn't provide additional semantic context for headers or timeout.

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 JSON from a URL, parse it, and return it formatted') and distinguishes it from sibling tools (fetch_image, fetch_url) by specifying JSON data retrieval and parsing. It explicitly mentions 'prettified for better readability' which adds differentiation.

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

Usage Guidelines4/5

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

The description provides clear context about when to use this tool ('retrieve and parse JSON data from any accessible web URL'), but doesn't explicitly state when NOT to use it or mention alternatives like fetch_url for non-JSON content. It implies usage for JSON data specifically, which is helpful but not fully comparative.

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

fetch_urlC

Fetch content from a URL and return it as text.

This tool allows Claude to retrieve content from any accessible web URL.
The content is returned as text, making it suitable for HTML, plain text,
and other text-based content types.

ParametersJSON Schema

Name	Required	Description
`headers`	No	Additional headers to send with the request
`timeout`	No	Request timeout in seconds
`url`	Yes	The URL to fetch

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 mentions that content is returned as text and is suitable for text-based content types, but lacks details on error handling, rate limits, authentication needs, or what happens with non-text content. 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.

Conciseness4/5

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

The description is appropriately sized and front-loaded, with the core purpose stated first. It consists of three sentences that are relevant, though the second sentence ('This tool allows Claude to retrieve content...') could be considered slightly redundant with the first. Overall, it's efficient with minimal waste.

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

Completeness3/5

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

Given that an output schema exists (as indicated in context signals), the description doesn't need to explain return values. However, with no annotations and three parameters, the description could do more to address behavioral aspects like error cases or limitations. It's adequate but has clear gaps in completeness for a tool with no annotations.

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 (url, headers, timeout) thoroughly. The description doesn't add any parameter-specific information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.

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 content from a URL and return it as text.' It specifies the verb ('fetch'), resource ('content from a URL'), and outcome ('return it as text'). However, it doesn't explicitly differentiate from sibling tools like fetch_image and fetch_json, which likely handle different content types.

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 minimal usage guidance. It mentions 'any accessible web URL' and suitability for 'HTML, plain text, and other text-based content types,' but doesn't specify when to use this tool versus fetch_image or fetch_json, nor does it provide exclusions or alternatives. No explicit when/when-not guidance is present.

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.

3 tool updatesv1.0.0Jul 22, 2025
- First observedfetch_image
- First observedfetch_json
- First observedfetch_url

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

A3.5/5.0

Scored 2026-04-18 11:10 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: fetch_image retrieves images, fetch_json retrieves and parses JSON, and fetch_url retrieves general text content. The descriptions reinforce these distinctions, making it easy for an agent to select the right tool based on the expected response format.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'fetch_' prefix and descriptive suffixes (image, json, url). This predictable naming scheme enhances usability and reduces cognitive load for agents.

Tool Count4/5

Three tools is a reasonable count for a URL fetching server, covering the main content types (images, JSON, text). It's slightly lean but well-scoped; adding tools for other formats like XML or binary data could improve completeness without being excessive.

Completeness4/5

The tools cover the core use cases for fetching web content: images, JSON, and general text. A minor gap exists for other structured data formats like XML or raw binary files, but agents can work around this by using fetch_url for text-based alternatives or requesting enhancements.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3
Jina Reader A
io.github.pipeworx-io
Jina AI Reader/Search MCP — turn any URL into clean LLM-ready markdown, plus web search.
Web Scraping Search
332
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

Related MCP Servers

MCP Web Research Server
Browser Automation Web Scraping Search
mzxrai
A
license
B
quality
F
maintenance
A Model Context Protocol (MCP) server for web research. Bring real-time info into Claude and easily research any topic.
Updated 2 years ago (2024-12-18 03:38 UTC)
3
1,202 npm
300
MIT
@kazuph/mcp-fetch
Browser Automation Image & Video Processing
kazuph
A
license
A
quality
C
maintenance
Model Context Protocol server for fetching web content and processing images. This allows Claude Desktop (or any MCP client) to fetch web content and handle images appropriately.
Updated 3 months ago (2026-06-12 13:45 UTC)
1
871 npm
41
MIT
MCP-RQuest
Browser Automation Web Scraping
xxxbrian
A
license
B
quality
C
maintenance
A Model Context Protocol server that enables Claude and other LLMs to make HTTP requests with realistic browser fingerprinting, bypassing common anti-bot measures and interacting with websites more naturally.
Updated a year ago (2025-03-22 17:36 UTC)
12
48
MIT
MCP Fetch
Browser Automation Image & Video Processing Web Scraping
JeremyNixon
A
license
A
quality
D
maintenance
Model Context Protocol server that enables Claude Desktop (or any MCP client) to fetch web content and process images appropriately.
Updated 2 years ago (2025-01-12 09:51 UTC)
1
277 npm
MIT

URL 获取 MCP

特征

存储库结构

安装

用法

运行服务器

在 Claude Desktop 中安装

方法一：直接安装

方法 2：使用安装程序脚本

方法 3：使用 CLI 命令

核心实现

工具功能

fetch_url

获取图像

fetch_json

示例

测试

执照

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches