Skip to main content
Glama
MCP01: Google HTML Fetcher MCP Server

MCP01: Google HTML Fetcher MCP Server

by hirenputu

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 npx or npm.


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

url

string

No

https://www.google.com

Target URL to fetch

filename

string

No

google.html

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-fetcher

Check status anytime:

agy mcp list

Option 2: Run via NPM from GitHub

Run on-demand:

npx -y github:hirenputu/mcp01-google-fetcher

Or install globally:

npm install -g github:hirenputu/mcp01-google-fetcher
mcp01

Option 3: Local Development

Clone this repository and run locally:

npm install
node index.js

Environment Configuration

Variable

Description

Default

MCP_OUTPUT_DIR

Directory where HTML files will be saved

C:\Users\hiren\Documents\mcpserver\mcp01


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 tool
fetch_google_htmlB

Connects to google.com, fetches the HTML source of the page, and stores it in C:\Users\hiren\Documents\mcpserver\mcp01

NameRequiredDescriptionDefault
urlNoOptional URL to fetch (defaults to 'https://www.google.com')https://www.google.com
filenameNoOptional output filename (defaults to 'google.html')google.html

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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. 1 tool updatev1.0.0
    • First observedfetch_google_html

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness2/5

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

ActivityMaintained
ResponsivenessNo recent community issues

Related MCP Connectors

Related MCP Servers