Which integrations are available for this server?

Uses Pydantic for type validation of URL parameters and request configuration

How do I use URL Fetch MCP?

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., "@URL Fetch MCP fetch the latest blog post from example.com" 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.

en es ja ko zh

URL Fetch MCP

by aelaguiz

Overview Schema Related Servers Score Discussions

Python

Hybrid

URL Fetch MCP

A clean Model Context Protocol (MCP) implementation that enables Claude or any LLM to fetch content from URLs.

Features

Fetch content from any URL
Support for multiple content types (HTML, JSON, text, images)
Control over request parameters (headers, timeout)
Clean error handling
Works with both Claude Code and Claude Desktop

Related MCP server: @kazuph/mcp-fetch

Repository Structure

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

Installation

# Install from source
pip install -e .

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

Usage

Running the Server

# 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

Installing in Claude Desktop

There are three ways to install in Claude Desktop:

Method 1: Direct installation

# Install the package
pip install -e .

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

The url_fetcher.py file contains:

#!/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()

Method 2: Use the installer script

# Install the package
pip install -e .

# Run the installer script
python scripts/install_desktop.py

The scripts/install_desktop.py script:

#!/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())

Method 3: Use CLI command

# Install the package
pip install -e .

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

Core Implementation

The main MCP implementation is in 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...

Tool Capabilities

fetch_url

Fetches content from a URL and returns it as text.

Parameters:

url (required): The URL to fetch
headers (optional): Additional headers to send with the request
timeout (optional): Request timeout in seconds (default: 10)

fetch_image

Fetches an image from a URL and returns it as an image.

Parameters:

url (required): The URL to fetch the image from
timeout (optional): Request timeout in seconds (default: 10)

fetch_json

Fetches JSON from a URL, parses it, and returns it formatted.

Parameters:

url (required): The URL to fetch JSON from
headers (optional): Additional headers to send with the request
timeout (optional): Request timeout in seconds (default: 10)

Examples

The examples directory contains example scripts:

quick_test.py: Quick test of the MCP server
simple_usage.py: Example of using the client API
interactive_client.py: Interactive CLI for testing

# 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"
})

Testing

To test basic functionality:

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

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

License

MIT

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

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

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: 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

Unclaimed servers have limited discoverability.

Looking for Admin?

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

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
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
1,247
41
MIT
MCP-RQuest
Browser Automation Web Scraping
xxxbrian
A
license
Not graded
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)
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
170
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/aelaguiz/mcp-url-fetch'

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