Skip to main content
Glama
enesjakozh
TheSethRose

Fetch Browser

by TheSethRose
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Fetch Browser

A powerful headless browser MCP server that enables AI agents to fetch web content and perform Google searches without requiring any API keys. Built with modern web standards and designed for seamless integration with AI platforms.

Features

  • No API Keys Required: Uses a sophisticated headless browser approach to fetch content directly

  • Smart Google Search:

    • Extract structured results from Google searches

    • Support for both web and news results

    • Configurable number of results (1-100)

    • Full content fetching of search results

    • Automatic retry and error handling

  • Universal Content Fetching:

    • Support for any webpage or API endpoint

    • Multiple output formats (HTML, JSON, Text, Markdown)

    • Automatic content type detection

    • Response size limits and timeout protection

    • Rate limiting protection

  • Format Conversion:

    • Clean HTML to Markdown conversion

    • Pretty-printed JSON responses

    • Structured HTML output

    • Plain text with proper formatting

Related MCP server: Local Browser MCP

Tools

1. Google Search Tool (google_search)

Executes Google searches and fetches full content of results:

{
  query: "your search query",
  responseType: "markdown", // or "json", "html", "text"
  maxResults: 10,          // 1-100 results
  topic: "web"            // or "news"
}

2. URL Fetcher Tool (fetch_url)

Fetches content from any URL:

{
  url: "https://example.com",
  responseType: "markdown", // or "json", "html", "text"
  timeout: 30000          // optional, in milliseconds
}

Installation

Via Smithery

# For Claude
npx -y @smithery/cli install @TheSethRose/fetch-browser --client claude

# For Cursor
npx -y @smithery/cli install @TheSethRose/fetch-browser --client cursor

# For TypeScript
npx -y @smithery/cli install @TheSethRose/fetch-browser --client typescript

Manual Installation

# Clone the repository
git clone https://github.com/TheSethRose/fetch-browser.git
cd fetch-browser

# Install dependencies
npm install

# Build the project
npm run build

# Start the server
npm start

Development

# Watch mode with auto-rebuild
npm run watch

# Run with inspector
npm run inspector

# Debug mode
npm run debug

# Debug with watch mode
npm run debug:watch

Response Formats

1. Markdown Format

## [Page Title](https://example.com)

Content converted to clean markdown with:
- Lists
- **Bold text**
- *Italic text*
- [Links](https://example.com)

2. JSON Format

{
  "url": "https://example.com",
  "content": "Extracted content...",
  "error": null
}

3. HTML Format

<div class="search-result">
  <h2><a href="https://example.com">Page Title</a></h2>
  <div class="content">
    Original HTML content
  </div>
</div>

4. Text Format

### https://example.com

Plain text content with preserved formatting
==========

Error Handling

  • Automatic retries with exponential backoff

  • Rate limiting protection

  • Timeout handling

  • Detailed error messages

  • Individual result error tracking

Security Features

  • Response size limits

  • Request timeouts

  • Rate limiting protection

  • No API keys or secrets required

  • Proper error handling

Credits

Created by Seth Rose:

License

MIT License - See LICENSE for details

Available Tools

2 tools
fetch_urlC

Fetch content from a URL with proper error handling and response processing

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to fetch
responseTypeNoExpected response typetext
timeoutNoRequest timeout in milliseconds

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'proper error handling and response processing', which hints at robustness, but lacks specifics on authentication needs, rate limits, retry behavior, or what constitutes 'proper' processing. This is insufficient for a tool that interacts with external URLs.

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 a single, efficient sentence that front-loads the core purpose. However, it could be more structured by separating purpose from behavioral claims, and the phrase 'proper error handling and response processing' is somewhat vague and could be tightened.

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 fetching from URLs (potential for errors, varied content types) and the absence of annotations and output schema, the description is incomplete. It doesn't cover return values, error formats, or detailed behavioral traits needed for reliable use by an AI agent.

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 thoroughly. The description adds no additional meaning about parameters beyond what's in the schema, such as explaining the implications of different response types or timeout values. Baseline 3 is appropriate when 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 ('fetch content from a URL') and resource ('URL'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'google_search', which likely serves a different purpose (searching vs. direct fetching).

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 no guidance on when to use this tool versus alternatives like 'google_search'. It mentions 'proper error handling and response processing' but doesn't specify scenarios, prerequisites, or exclusions for usage.

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.

  1. 2 tool updates
    • First observedfetch_url
    • First observedgoogle_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: fetch_url retrieves content from a specific URL, while google_search performs web searches and returns results. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the task.

Naming Consistency4/5

Both tools follow a verb_noun pattern (fetch_url, google_search), which is consistent and predictable. The minor deviation is that google_search includes a brand name, but this does not break the overall naming convention.

Tool Count3/5

With only 2 tools, the server feels thin for a browser-related purpose, as it lacks common operations like navigating pages, handling cookies, or interacting with web elements. However, the tools provided are core functionalities, so it's borderline appropriate.

Completeness2/5

For a browser server, there are significant gaps in coverage, such as no tools for page navigation, form submission, JavaScript execution, or session management. The surface is severely incomplete for typical browser automation tasks, limiting agent effectiveness.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • mult-fetch-mcp-server

    lmcc-dev
    A
    license
    A
    quality
    C
    maintenance
    An MCP server that enables AI assistants to fetch web content in multiple formats (HTML, JSON, text, Markdown) with intelligent content extraction, chunk management, and browser automation support.
    5
    52
    15
    MIT

  • Local Browser MCP

    NolanLT
    A
    license
    A
    quality
    A
    maintenance
    A headless, agent-controllable real browser as an MCP server that enables AI agents to navigate, click, fill, eval JavaScript, and take screenshots on localhost and allowed hosts, with no GUI required.
    27
    4
    MIT

  • krwl3r

    garciarsdiego
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for web scraping and browser automation, enabling AI agents to extract clean, token-efficient content from web pages.
    1
    MIT
  • Wick by wickproject

    Wickofficial

    wickproject
    F
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that provides browser-grade web access for AI agents, using Chrome's actual network stack to bypass anti-bot protections and return clean markdown.
    8
    -

Appeared in Searches

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/TheSethRose/Fetch-Browser'

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