auth-fetch-mcp enables AI assistants to fetch content from authenticated and dynamic web pages by automating browser-based login and content capture.
Fetch authenticated pages (auth_fetch): Opens a real browser to any URL (including login-required pages like Notion, Google Docs, Jira, Confluence, Linear, Slack, or any SaaS/private page), allows manual login (including SSO, 2FA, CAPTCHA), and captures the page as Markdown. Optionally specify a CSS selector (wait_for) to wait for specific elements before capturing — useful for Single Page Applications (SPAs).
List open browser tabs (list_pages): View all currently open tabs with their URLs and titles.
Close the browser (close_browser): Close the browser window while preserving login sessions for future reuse.
Persist login sessions: Browser data is saved locally (~/.auth-fetch-mcp/browser-data/), so you only need to log in once per service.
Local & private: Runs entirely on your local machine, communicating with AI tools (Claude Code, Cursor, Windsurf, or any MCP client) via stdio, keeping all data local.
Enables fetching and capturing content from authenticated Notion pages, allowing AI assistants to read and summarize private workspace content by using a real browser to handle logins and session persistence.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@auth-fetch-mcp Summarize this private Notion page: https://notion.so/my-project-notes"
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.
MCP server that lets AI assistants fetch content from authenticated web pages.
When your AI tries to read a URL that requires login, this tool opens a real browser for you to sign in — then captures the page content as cleaned HTML. Sessions are saved locally, so you only log in once per service.
Related MCP server: byob
claude mcp add --scope user auth-fetch -- npx auth-fetch-mcp@latest{
"mcpServers": {
"auth-fetch": {
"command": "npx",
"args": ["auth-fetch-mcp@latest"]
}
}
}Chromium is auto-installed on first run if not already present.
Ask your AI to read any authenticated page — just paste the URL.
A browser window opens automatically and navigates to the page.
Log in as you normally would (supports SSO, 2FA, CAPTCHA — anything).
Click the "📸 Capture" button in the bottom-right corner when ready.
The page content is captured as cleaned HTML (noise elements stripped, media tags preserved), the browser closes, and your AI receives the content.
auth_fetchThe primary tool. Fetches page content using a real browser, opening a window for login if needed. Returns cleaned HTML with noise elements (nav, footer, scripts, etc.) stripped and media tags (<img>, <video>, <iframe>) preserved.
Parameter | Type | Required | Description |
| string | yes | The URL to fetch content from (only |
| string | no | CSS selector to wait for before capturing (useful for SPAs) |
download_mediaDownloads files from URLs using saved browser sessions. Use this to lazily download images, videos, or other files found in auth_fetch results. The browser's saved cookies handle authentication automatically — no need to log in again.
Parameter | Type | Required | Description |
| string[] | yes | One or more URLs to download (only |
| string | no | Subdirectory under |
Example flow:
1. auth_fetch("https://notion.so/my-page")
→ Returns HTML with <img src="https://s3.notion.so/signed-url..."/> tags
2. AI reads the HTML, identifies an image it needs
3. download_media(["https://s3.notion.so/signed-url..."])
→ Downloads the image using saved session cookies
→ Returns { localPath: "~/.auth-fetch-mcp/downloads/.../file-1.png" }list_pagesLists all open tabs in the browser with their URLs and titles.
close_browserCloses the browser window. Login sessions are saved and will be reused next time.
To prevent SSRF (server-side request forgery) attacks driven by prompt injection, both auth_fetch and download_media validate every URL before dispatching it:
Only http and https schemes are allowed. file:, data:, javascript:, etc. are rejected.
The hostname is resolved via DNS and the resulting IP is checked. Requests are rejected when the address falls in private, loopback, link-local, CGNAT, or multicast ranges:
IPv4: 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.168.0.0/16, 198.18.0.0/15, 224.0.0.0/4, 240.0.0.0/4
IPv6: ::, ::1, fc00::/7, fe80::/10, ff00::/8, IPv4-mapped equivalents
download_media additionally constrains output_dir to stay inside ~/.auth-fetch-mcp/downloads/. Absolute paths and .. segments that escape this root are rejected.
If you need to access a host on your local machine or LAN (e.g., a dev server, NAS, or Tailscale node), opt in with environment variables:
Variable | Effect |
| Set to |
| Comma-separated allowlist of hostnames or IPs. Matches against the URL's hostname and every resolved IP. |
.mcp.json example:
{
"mcpServers": {
"auth-fetch": {
"command": "npx",
"args": ["auth-fetch-mcp@latest"],
"env": {
"AUTH_FETCH_ALLOW_HOSTS": "localhost,127.0.0.1,192.168.1.10"
}
}
}
}Heads up: enabling these variables re-opens those hosts to any prompt the MCP client (LLM) processes. Prefer the narrowest possible allowlist over
AUTH_FETCH_ALLOW_PRIVATE=1, and only enable them in environments you trust.
All data is stored locally under ~/.auth-fetch-mcp/. Nothing is sent to external servers.
What | Where | When | Persistent? |
Browser sessions (cookies, local storage) |
| After first login | Yes — reused across restarts |
Downloaded media files |
| Only when | Yes — stays until you delete it |
Captured page content (HTML) | Not saved to disk | Passed directly to AI via stdio | No — exists only in the AI's context |
To clear all data:
# Clear login sessions only
rm -rf ~/.auth-fetch-mcp/browser-data/
# Clear downloaded files only
rm -rf ~/.auth-fetch-mcp/downloads/
# Clear everything
rm -rf ~/.auth-fetch-mcp/Claude Code
Cursor
Windsurf
Any MCP-compatible client using stdio transport
Requires a local environment (does not work in web-based chat interfaces)
First access to each service requires manual login
Very long pages are truncated to fit LLM context windows (100K chars)
Some sites with aggressive bot detection may not work (try the wait_for option)
Private, loopback, and link-local hosts are blocked by default — opt in via AUTH_FETCH_ALLOW_PRIVATE / AUTH_FETCH_ALLOW_HOSTS (see URL restrictions)
All data stays on your machine — nothing is sent to external servers
Captured HTML is never written to disk — it only passes through the stdio pipe to the AI tool
Browser sessions are stored locally as a standard Chromium profile
Downloaded files go to a local directory you control
Contributions are welcome! Please open an issue or submit a pull request.
git clone https://github.com/ymw0407/auth-fetch-mcp.git
cd auth-fetch-mcp
npm install
npm run buildMIT
Fetches web page content using a real browser and returns cleaned HTML. MUST be used instead of Fetch/web_fetch when the page requires login or returns empty/minimal HTML (e.g. Notion, Google Docs, Jira, Confluence, Linear, Slack, or any SaaS/private page). Do NOT suggest copy-paste or PDF export — use this tool first. Opens a browser window, the user logs in if needed, clicks the capture button, and the content is returned as cleaned HTML (noise stripped, media preserved). To download images or files from the result, use download_media with the URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch content from | |
| wait_for | No | Optional CSS selector to wait for before capturing (useful for SPAs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains the tool opens a browser window, requires user interaction (login, click capture), returns cleaned HTML with noise stripped and media preserved, and directs to download_media for image/file downloads. All behavioral traits are disclosed.
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 paragraph but covers all key points without redundancy. Each sentence contributes meaning. Could be slightly more structured but remains efficient.
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 an auth-fetching tool, the description explains the user interaction flow, output format (cleaned HTML), and references a sibling tool (download_media). No output schema exists, but description provides enough for agent to understand usage.
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 coverage is 100%. Description adds context for 'url' (the URL to fetch) and 'wait_for' (optional CSS selector for SPAs). This adds value beyond schema definitions.
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 it fetches web page content using a real browser and returns cleaned HTML. It distinguishes from siblings by specifying it is for pages requiring login or returning empty HTML, and lists examples like Notion, Google Docs, Jira, Confluence, Linear, Slack, or any SaaS/private page.
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?
Explicitly states 'MUST be used instead of Fetch/web_fetch when the page requires login or returns empty/minimal HTML' and 'Do NOT suggest copy-paste or PDF export — use this tool first.' It outlines a workflow but does not explicitly exclude use cases for simple public pages where a simpler tool suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Closes the browser window. Login sessions are saved and will be reused next time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses a key behavioral trait: login sessions are saved and reused. This goes beyond the simple action by explaining the persistent effect. However, it does not mention other potential behaviors like confirmation dialogs or error states.
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 extremely concise with two sentences. The first sentence front-loads the core action, and the second adds a valuable behavioral detail. Every word earns its place.
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 simplicity (no parameters, no output schema) and the richness of the description (clear action plus saved sessions), the description is fully complete for an AI agent to understand what the tool does and its side effect.
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?
There are no parameters (0), and schema coverage is trivially 100%. The description correctly implies that no input is needed. For zero-parameter tools, the baseline is 4, and the description meets that by not adding unnecessary information.
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 ('Closes the browser window') and specifies the resource (browser window). It is a specific verb+resource pair that leaves no ambiguity, and it naturally distinguishes from sibling tools which deal with fetching, downloading, or listing.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., a browser must be open) or when not to use it (e.g., when you want to discard sessions). The description is purely declarative without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Downloads files from URLs using saved browser sessions. Use this to download images, videos, or other files found in auth_fetch results. The browser's saved cookies handle authentication automatically — no need to log in again.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | One or more URLs to download | |
| output_dir | No | Optional directory to save files to. Defaults to ~/.auth-fetch-mcp/downloads/<timestamp>/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that browser cookies handle authentication automatically, a key behavioral trait. But with no annotations, fails to address potential side effects like file overwriting, disk space usage, or error handling. Moderate added context over minimal structured fields.
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?
Three concise sentences with no redundancy. Front-loaded with verb 'Downloads'. Each sentence adds value: purpose, usage context, authentication advantage.
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 simple two-parameter tool with no output schema, description covers main purpose and usage context. Missing information on return value (e.g., saved file paths) and potential limitations (browser state dependency). Adequate but not exhaustive.
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 coverage is 100%, so baseline is 3. Description adds no additional meaning about URL format or output_dir behavior beyond schema descriptions. Merely reinforces surrounding context.
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?
Description clearly states it downloads files from URLs using saved browser sessions. It specifies resource (files) and mechanism (browser sessions). Mentions relationship to auth_fetch, distinguishing from sibling fetch tool. However, lacks explicit differentiation from general download tools or caveats.
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?
Explicitly recommends use for downloading files from auth_fetch results. Highlights automatic authentication as key advantage. No explicit 'when not to use' or alternative tools, but sibling context provides implicit distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all open tabs in the browser with their URLs and titles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the behavior: listing open tabs with URLs and titles. It does not mention edge cases (e.g., no open tabs), but for a simple read operation, this is adequate.
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, clear sentence with no unnecessary words. It is front-loaded and efficient.
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 has no parameters, no output schema, and is a simple list operation, the description is complete. It explains the tool's purpose and output adequately.
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?
There are no parameters, and schema coverage is 100% (trivially). According to the rubric, no parameters set a baseline of 4. The description does not need to add parameter information.
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 'Lists all open tabs in the browser with their URLs and titles,' providing a specific verb and resource. The sibling tools (auth_fetch, close_browser, download_media) have distinct purposes, so no confusion.
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 does not explicitly state when or when not to use this tool, nor does it mention alternatives. However, the sibling tools are sufficiently different that usage context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
download_mediav2.0.7auth_fetchclose_browserlist_pagesEach tool has a distinct purpose: auth_fetch for fetching content from authenticated pages, close_browser for closing the browser, download_media for downloading files, and list_pages for listing open tabs. No functional overlap.
All tool names follow a consistent verb_noun snake_case pattern (auth_fetch, close_browser, download_media, list_pages), making predictions easy.
Four tools cover the essential operations for an authenticated browser session management server: fetch, close, download, and list. The scope is well-defined and not excessive.
The tool set provides complete coverage of the core workflow: fetching authenticated content, managing the browser session (close, list tabs), and downloading associated media. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Save and organize web finds in persistent, user-controlled collections for AI assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ymw0407/auth-fetch-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
