Skip to main content
Glama
belzorash

cleanfetch

by belzorash
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

cleanfetch

An MCP server that gives AI agents clean, reliable web reading. One job, done well.

Tool

Input

Output

fetch_clean

a URL

the page's main content as clean Markdown + title/byline (nav/ads/scripts stripped)

extract_links

a URL

all hyperlinks with anchor text, classified internal/external

extract_metadata

a URL

title, description, canonical, robots, Open Graph, JSON-LD, headings outline

Why this exists

Agent builders constantly need to read web pages — but the generic fetchers choke on real-world HTML, return nav/ad noise, or get blocked. Reliability is the moat: a server that consistently returns clean, structured content is worth paying for. There are 14,000+ MCP servers listed and almost none are production-hardened or monetized — that's the opening.

Related MCP server: markfetch-mcp

Run it locally

npm install
npm run build
npm start          # runs on stdio
# or, no build step:
npm run dev

Sanity-check the tools with the MCP Inspector:

npm run inspect

Connect it to a client

Claude Desktop / Claude Code / Cursor — add to the MCP config:

{
  "mcpServers": {
    "cleanfetch": {
      "command": "node",
      "args": ["/Users/alexandre/projects/mcp-cleanfetch/dist/index.js"]
    }
  }
}

Then ask the agent: "Use fetch_clean to read https://example.com and summarize it."

Config (env vars)

  • CLEANFETCH_UA — override the User-Agent.

  • CLEANFETCH_TIMEOUT_MS — request timeout (default 15000).

Go-to-market (the actual point)

1. List it everywhere (free distribution). Submit to the MCP directories — this is the "App Store moment", and free-tier listings rank highest:

Publish to npm so npx mcp-cleanfetch works, and add a 30-second demo GIF to the README.

2. Harden the moat (what makes it paid-worthy). Roadmap, in order of value:

  • JS rendering fallback (Playwright) for client-side-rendered pages.

  • Rotating proxies + retry/anti-bot handling for sites that block plain fetch.

  • Caching + rate limiting.

  • batch_fetch (many URLs in one call), search (query → top results → clean content).

3. Monetize. Free tier = local stdio (what's here). Paid tier = a hosted HTTP MCP endpoint with an API key + usage billing:

  • Host the server over the Streamable HTTP transport (the SDK supports it).

  • Meter calls per key; bill with Stripe (Stripe shipped MCP/usage billing rails in 2026) or a usage-billing layer. Typical pricing in this category: a free tier + ~$20–40/mo, or per-call credits. Realistic target: $0.5–3K MRR per server — cheap enough to run several.

4. Validate before hardening. Ship the free version, list it, and watch installs/usage. If a tool gets real pull, that's the signal to build the paid hosted tier. Don't build billing for a server nobody installs.

License

MIT

Available Tools

3 tools
extract_metadataExtract structured metadataA

Fetch a page and return structured metadata: title, description, canonical URL, robots, Open Graph tags, JSON-LD blocks, and a headings outline. Lets an agent analyze a page's structure without reading the whole body.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe page URL to fetch

TDQS

A3.8/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. It describes the read-only fetch and return of metadata but omits any potential limitations, error conditions, or side effects. Behavior is implied but not fully disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with clear structure: action first, then list of outputs, then purpose. No unnecessary words; front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single required parameter and no output schema, the description sufficiently explains the tool's function and return content. It could be more complete by noting that output is in JSON or similar, but not essential.

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 coverage is 100%, so baseline is 3. The tool description adds no extra meaning beyond the schema's parameter description 'The page URL to fetch'. No additional context is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches a page and returns structured metadata, listing specific elements (title, description, etc.). It distinguishes from siblings by implying extract_links and fetch_clean serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions analyzing structure without reading the whole body, which implies a use case. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it compare directly to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_cleanFetch page as clean MarkdownA

Fetch a web page and return its main article content as clean Markdown plus core metadata (title, byline). Strips navigation, ads, and scripts so an agent can read the page reliably.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe page URL to fetch
maxCharsNoTruncate the returned Markdown to this many characters

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It mentions stripping navigation, ads, and scripts, but does not disclose potential issues like rate limits, authentication, error handling, or what happens if the page fails to parse correctly. The description is adequate but could be more transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no wasted words. It front-loads the main purpose and provides just enough detail for the agent to understand the tool's core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema), the description is fairly complete. It explains the purpose, what is stripped, and what is returned. However, for completeness, it could mention behavior on errors or redirects, but this is not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters described). The description adds meaning by specifying the output format (clean Markdown) and included metadata (title, byline), which is not in the schema. This adds value beyond the parameter names and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Fetch'), the resource ('web page'), and the output ('clean Markdown plus core metadata'). It also implicitly distinguishes from siblings like extract_links and extract_metadata by focusing on content extraction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the intended use case: fetching a page to get clean, readable content for an agent. It does not explicitly state when not to use it or mention alternatives, but the context of sibling tools provides some differentiation.

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. 3 tool updatesv0.1.0
    • First observedextract_links
    • First observedextract_metadata
    • First observedfetch_clean
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct aspect of web page analysis: links, metadata, and clean content. There is no functional overlap between extract_links, extract_metadata, and fetch_clean.

Naming Consistency4/5

Tools follow a verb_noun pattern, but fetch_clean uses 'fetch' while the other two use 'extract'. This is a minor inconsistency but still clear and predictable.

Tool Count5/5

Three tools is a well-scoped set for a clean fetching utility, covering the essential operations without unnecessary complexity.

Completeness5/5

The tools cover all key aspects of web page extraction: links, metadata, and clean content. No obvious gaps for the stated purpose of agent navigation and analysis.

Maintenance

ActivityStale
ResponsivenessSyncing

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

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/belzorash/mcp-cleanfetch'

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