Fetch Browser
브라우저 가져오기
AI 에이전트가 API 키 없이 웹 콘텐츠를 가져오고 Google 검색을 수행할 수 있도록 지원하는 강력한 헤드리스 브라우저 MCP 서버입니다. 최신 웹 표준을 기반으로 구축되었으며 AI 플랫폼과 완벽하게 통합되도록 설계되었습니다.
특징
API 키 필요 없음 : 정교한 헤드리스 브라우저 방식을 사용하여 콘텐츠를 직접 가져옵니다.
스마트한 구글 검색 :
Google 검색에서 구조화된 결과 추출
웹 및 뉴스 결과 모두 지원
구성 가능한 결과 수(1~100)
검색 결과의 전체 콘텐츠 가져오기
자동 재시도 및 오류 처리
유니버설 콘텐츠 페칭 :
모든 웹 페이지 또는 API 엔드포인트 지원
다양한 출력 형식(HTML, JSON, 텍스트, 마크다운)
자동 콘텐츠 유형 감지
응답 크기 제한 및 시간 초과 보호
속도 제한 보호
형식 변환 :
깔끔한 HTML을 마크다운으로 변환
예쁘게 인쇄된 JSON 응답
구조화된 HTML 출력
적절한 서식이 적용된 일반 텍스트
Related MCP server: Local Browser MCP
도구
1. 구글 검색 도구( google_search )
Google 검색을 실행하고 결과의 전체 내용을 가져옵니다.
지엑스피1
2. URL 가져오기 도구( fetch_url )
모든 URL에서 콘텐츠를 가져옵니다.
{
url: "https://example.com",
responseType: "markdown", // or "json", "html", "text"
timeout: 30000 // optional, in milliseconds
}설치
스미서리를 통해
# 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수동 설치
# 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개발
# 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응답 형식
1. 마크다운 형식
## [Page Title](https://example.com)
Content converted to clean markdown with:
- Lists
- **Bold text**
- *Italic text*
- [Links](https://example.com)2. JSON 형식
{
"url": "https://example.com",
"content": "Extracted content...",
"error": null
}3. HTML 형식
<div class="search-result">
<h2><a href="https://example.com">Page Title</a></h2>
<div class="content">
Original HTML content
</div>
</div>4. 텍스트 형식
### https://example.com
Plain text content with preserved formatting
==========오류 처리
지수 백오프를 통한 자동 재시도
속도 제한 보호
타임아웃 처리
자세한 오류 메시지
개별 결과 오류 추적
보안 기능
응답 크기 제한
요청 시간 초과
속도 제한 보호
API 키나 비밀번호가 필요하지 않습니다
적절한 오류 처리
크레딧
Seth Rose가 생성함 :
웹사이트 : https://www.sethrose.dev
𝕏 (트위터) : https://x.com/TheSethRose
🔥 (블루스카이) : https://bsky.app/profile/sethrose.dev
특허
MIT 라이선스 - 자세한 내용은 라이선스를 참조하세요.
Available Tools
2 toolsfetch_urlC
Fetch content from a URL with proper error handling and response processing
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch | |
| responseType | No | Expected response type | text |
| timeout | No | Request timeout in milliseconds |
TDQS
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.
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.
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.
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.
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.
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.
google_searchC
Execute a Google search and return results in various formats
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to execute | |
| responseType | No | Expected response type | json |
| maxResults | No | Maximum number of results to return | |
| topic | No | Type of search to perform | web |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the action and output formats. It fails to disclose critical behavioral traits such as rate limits, authentication needs, network dependencies, or error handling. The description is minimal and doesn't compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and outcome with zero waste. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with multiple parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain result formats, error cases, or operational constraints, leaving significant gaps for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as explaining the impact of 'responseType' choices or 'topic' differences. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('execute') and resource ('Google search') with the outcome ('return results in various formats'). It distinguishes from the sibling 'fetch_url' by focusing on search rather than URL retrieval. However, it doesn't specify what 'various formats' means beyond the schema's enum values, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'fetch_url' or other search methods. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
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.
2 tool updates
- First observed
fetch_url - First observed
google_search
TDQS
Scored across 2 tools
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.
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.
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.
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
Related MCP Connectors
Official Browserless MCP server: browser automation, scraping, screenshots and PDFs for AI agents.
Free web search for AI agents. No API key required. Hosted MCP in active development.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Turn any public website into an MCP server for agents to search, read and navigate.
Related MCP Servers
- AlicenseAqualityBmaintenanceAn 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.568 npm15MIT
- AlicenseBqualityAmaintenanceA 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.275MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for web scraping and browser automation, enabling AI agents to extract clean, token-efficient content from web pages.1MIT

Wickofficial
FlicenseNot gradedqualityBmaintenanceAn 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.9-