Skip to main content
Glama
amotivv

cloudflare-browser-rendering-mcp

fetch_page

Extract and process web page content for LLM context using a specified URL and optional content length limit. Integrates with Cloudflare Browser Rendering for direct functionality in Cline or Claude Desktop.

Instructions

Fetches and processes a web page for LLM context

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maxContentLengthNoMaximum content length to return
urlYesURL to fetch

Implementation Reference

  • The primary handler for the 'fetch_page' tool. Validates input arguments, fetches HTML content using BrowserClient, processes it for LLM use with ContentProcessor, applies length truncation, and returns formatted text content or error.
     * Handle the fetch_page tool
     */
    private async handleFetchPage(args: any) {
      // Validate arguments
      if (typeof args !== 'object' || args === null || typeof args.url !== 'string') {
        throw new McpError(ErrorCode.InvalidParams, 'Invalid arguments for fetch_page');
      }
    
      const { url, maxContentLength = 10000 } = args;
    
      try {
        // Fetch the page content
        const html = await this.browserClient.fetchContent(url);
        
        // Process the content for LLM
        const processedContent = this.contentProcessor.processForLLM(html, url);
        
        // Truncate if necessary
        const truncatedContent = processedContent.length > maxContentLength
          ? processedContent.substring(0, maxContentLength) + '...'
          : processedContent;
        
        // Return the content
        return {
          content: [
            {
              type: 'text',
              text: truncatedContent,
            },
          ],
        };
      } catch (error) {
        console.error('[Error] Error fetching page:', error);
        return {
          content: [
            {
              type: 'text',
              text: `Error fetching page: ${error instanceof Error ? error.message : String(error)}`,
            },
          ],
          isError: true,
        };
      }
    }
  • Tool schema definition including name, description, and input schema specifying 'url' (required) and optional 'maxContentLength'.
    {
      name: 'fetch_page',
      description: 'Fetches and processes a web page for LLM context',
      inputSchema: {
        type: 'object',
        properties: {
          url: {
            type: 'string',
            description: 'URL to fetch',
          },
          maxContentLength: {
            type: 'number',
            description: 'Maximum content length to return',
          },
        },
        required: ['url'],
      },
    },
  • src/server.ts:182-186 (registration)
    Registration in the tool dispatch switch statement within the CallToolRequestSchema handler, routing 'fetch_page' calls to handleFetchPage.
    switch (name) {
      case 'fetch_page':
        console.error(`[API] Fetching page: ${args?.url}`);
        return await this.handleFetchPage(args);
      case 'search_documentation':
  • Helper function in BrowserClient that performs the actual HTTP POST to Cloudflare Browser Rendering API (/content endpoint) to fetch rendered HTML, with error handling.
    async fetchContent(url: string): Promise<string> {
      try {
        console.error(`[API] Fetching content from: ${url}`);
        
        // Make the API call to the Cloudflare Worker
        const response = await axios.post(`${this.apiEndpoint}/content`, {
          url,
          rejectResourceTypes: ['image', 'font', 'media'],
          waitUntil: 'networkidle0',
        });
        
        // Check if the response has the expected structure
        if (response.data && response.data.content) {
          return response.data.content;
        }
        
        // If we can't find the content, log the response and throw an error
        console.error('[Error] Unexpected response structure:', JSON.stringify(response.data, null, 2));
        throw new Error('Unexpected response structure from Cloudflare Worker');
      } catch (error: any) {
        console.error('[Error] Error fetching content:', error);
        
        // Log more detailed error information if available
        if (error.response) {
          console.error('[Error] Response status:', error.response.status);
          console.error('[Error] Response data:', JSON.stringify(error.response.data, null, 2));
        }
        
        throw new Error(`Failed to fetch content: ${error instanceof Error ? error.message : String(error)}`);
      }
    }
  • Helper function that orchestrates content processing: extracts metadata, cleans HTML to markdown-like text, and formats with metadata for LLM context.
    processForLLM(html: string, url: string): string {
      // Extract metadata
      const metadata = this.extractMetadata(html, url);
      
      // Clean the content
      const cleanedContent = this.cleanContent(html);
      
      // Format for LLM context
      return this.formatForLLM(cleanedContent, metadata);
    }
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 'fetches and processes' but doesn't specify what processing entails (e.g., cleaning HTML, extracting text, handling errors), whether it requires authentication, rate limits, or what happens with invalid URLs. This leaves significant gaps for a tool that interacts with external resources.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place, making it easy for an agent to quickly grasp the tool's function.

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

Completeness2/5

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

Given the complexity of web fetching (external calls, potential errors) and lack of annotations or output schema, the description is insufficient. It doesn't explain return values, error handling, or processing behavior, leaving the agent with incomplete information for reliable tool invocation in varied contexts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for both parameters ('url' and 'maxContentLength'). The description adds no additional parameter semantics beyond what the schema provides, such as format details for URLs or units for content length. Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('fetches and processes') and resource ('a web page'), with the purpose being to provide 'LLM context'. It distinguishes from siblings like 'take_screenshot' (visual capture) and 'summarize_content' (summarization), though it doesn't explicitly differentiate from 'extract_structured_content' or 'search_documentation' which might have overlapping functionality.

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?

No guidance is provided on when to use this tool versus alternatives like 'extract_structured_content' or 'search_documentation'. The description implies usage for web page retrieval for LLM context, but lacks explicit when/when-not instructions or prerequisites, leaving the agent to infer based on tool names alone.

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/amotivv/cloudflare-browser-rendering-mcp'

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