Skip to main content
Glama
aelaguiz

URL Fetch MCP

by aelaguiz

fetch_url

Retrieve web content from any URL and convert it into text format. Ideal for accessing HTML, plain text, and other text-based resources directly for processing or analysis.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
headersNoAdditional headers to send with the request
timeoutNoRequest timeout in seconds
urlYesThe URL to fetch

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The core handler function for the 'fetch_url' tool. It performs an HTTP GET request using httpx, handles errors, logs via context, and returns the response text. The @app.tool() decorator registers it with the FastMCP server. Input schema is defined inline via Annotated types and Field descriptions.
    @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.
        
        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.
        """
        if ctx:
            await ctx.info(f"Fetching content from URL: {url}")
        
        request_headers = {
            "User-Agent": "URL-Fetch-MCP/0.1.0",
        }
        
        if headers:
            request_headers.update(headers)
        
        async with httpx.AsyncClient(follow_redirects=True, timeout=timeout) as client:
            try:
                response = await client.get(str(url), headers=request_headers)
                response.raise_for_status()
                
                content_type = response.headers.get("content-type", "text/plain")
                
                if ctx:
                    await ctx.info(f"Successfully fetched content ({len(response.text)} bytes, type: {content_type})")
                
                return response.text
            
            except Exception as e:
                error_message = f"Error fetching URL {url}: {str(e)}"
                if ctx:
                    await ctx.error(error_message)
                return error_message
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.

Install Server

Other Tools

Related Tools

Latest Blog Posts

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