MCP01: Google HTML Fetcher MCP Server
Fetches the HTML source of google.com (or another user-specified URL) and saves the response content to a local file, with HTTP status inspection.
Click on "Deploy 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., "@MCP01: Google HTML Fetcher MCP ServerFetch google.com and save the HTML as google.html"
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.
MCP01: Google HTML Fetcher MCP Server
A Model Context Protocol (MCP) server that connects to google.com, retrieves the page's HTML source, and stores it in your local directory.
Features
Standard MCP Protocol: Communicates using JSON-RPC 2.0 over standard I/O (
stdio).Webpage Fetching: Connects to
google.com(or user-defined target URL) with HTTP status inspection.Local Persistence: Writes the HTML response directly to a designated local path (defaults to
C:\Users\hiren\Documents\mcpserver\mcp01\google.html).Cloud-Ready / NPM Executable: Can be installed or run on-demand directly from GitHub via
npxornpm.
Related MCP server: Fetch MCP Server
Exposed MCP Tools
fetch_google_html
Fetches HTML source from google.com and writes the resulting content to disk.
Input Schema
Field | Type | Required | Default | Description |
| string | No |
| Target URL to fetch |
| string | No |
| Destination filename |
Installation & Usage
Option 1: Run & Add Directly in Antigravity CLI (agy) via GitHub
You can register this MCP server in agy directly from GitHub using npx:
agy mcp add mcp01 npx -y github:hirenputu/mcp01-google-fetcherCheck status anytime:
agy mcp listOption 2: Run via NPM from GitHub
Run on-demand:
npx -y github:hirenputu/mcp01-google-fetcherOr install globally:
npm install -g github:hirenputu/mcp01-google-fetcher
mcp01Option 3: Local Development
Clone this repository and run locally:
npm install
node index.jsEnvironment Configuration
Variable | Description | Default |
| Directory where HTML files will be saved |
|
Permissions & Security
Strict Access Control: No personal credentials, tokens, or private secrets are tracked in this repository.
Security Policy: For reporting vulnerabilities, consult SECURITY.md.
Network Boundaries: Only outbound HTTP GET requests are performed.
License
This project is licensed under the PolyForm Noncommercial License 1.0.0 - see the LICENSE file for details.
Available Tools
1 toolfetch_google_htmlB
Connects to google.com, fetches the HTML source of the page, and stores it in C:\Users\hiren\Documents\mcpserver\mcp01
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional URL to fetch (defaults to 'https://www.google.com') | https://www.google.com |
| filename | No | Optional output filename (defaults to 'google.html') | google.html |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the key side effect: a file is written to a hardcoded local directory. However, it says nothing about overwrite behavior when the file already exists, permission or network failure handling, or whether the tool returns the path or page content.
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?
A single sentence that front-loads the action and ends with the destination, with no filler. It could be tightened only by adding the missing behavioral detail rather than removing anything.
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?
For a two-optional-parameter write-side-effect tool with no annotations and no output schema, the description covers the core flow and destination but omits return value and overwrite semantics. That leaves a meaningful gap an agent would want before calling it repeatedly.
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% and both parameters are optional with documented defaults, so the schema does the heavy lifting and baseline 3 applies. The description adds no meaning about how 'url' interacts with the hardcoded destination path or how 'filename' changes the output location.
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 gives a specific verb chain (connects, fetches, stores) and a concrete resource (HTML source of google.com), so an agent can tell exactly what happens. It is slightly narrower than the schema, which allows an arbitrary URL, so the stated scope ('google.com') is more restrictive than the tool actually is.
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?
There is no when-to-use or when-not-to-use guidance, no prerequisites, and no alternatives named (though no siblings exist). The agent gets no signal about whether this is appropriate for scraping arbitrary pages or only for this one fixed target.
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.
1 tool update
v1.0.0- First observed
fetch_google_html
TDQS
Scored across 1 tool
With only one tool in the set, there is no possibility of overlap or misselection. The single tool's purpose (fetch google.com HTML and save it to disk) is unambiguous.
The lone name fetch_google_html follows a clean snake_case verb_noun pattern. There are no other names to conflict with, so consistency is trivially satisfied.
A single tool is borderline thin even for a narrowly scoped fetcher, and it bundles fetching plus file storage into one opaque operation. The scope is small enough that one tool is defensible, but it feels under-built.
The tool hardcodes google.com and a local Windows path, and there is no companion tool to read, list, or delete the stored HTML, so an agent cannot retrieve the fetched content. Coverage of even this tiny domain has a dead end at the output stage.
Maintenance
Related MCP Connectors
A simple tool that performs a fetch request to a webpage.
Shared copies of public web pages for AI agents. Search stored pages or fetch a URL.
Fetch web pages and extract exactly the content you need. Select elements with CSS and retrieve co…
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Related MCP Servers
- FlicenseBqualityDmaintenanceEnables fetching visible text content and extracting all links from web pages through URL requests. Designed specifically for LM Studio integration to provide web scraping capabilities.22-
- AlicenseBqualityDmaintenanceEnables LLMs to retrieve and process web content by fetching URLs and converting HTML to markdown format. Supports chunked reading of large pages and can access both public websites and local networks.1MIT
- AlicenseNot gradedqualityDmaintenanceFetches web content and returns it in HTML, JSON, plain text, or Markdown format.5,878 npmMIT
- AlicenseAqualityDmaintenanceEnables AI assistants to download files from HTTP/HTTPS URLs to local directories or file paths with options like custom filename, headers, and overwrite control.110 npmMIT