Allows performing web searches using DuckDuckGo, returning real result links (title, URL, snippet) via the web_search tool.
Allows performing web searches using Mojeek, an independent search index, returning real result links (title, URL, snippet) via the web_search tool.
Allows performing web searches using a SearXNG instance (self-hosted or public), returning result links, answers, infoboxes, and suggestions via the web_search tool.
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., "@NetLens fetch the full text of https://en.wikipedia.org/wiki/MCP"
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.
An MCP server for unobstructed web reading. It fetches any URL directly with
browser-like headers — past robots.txt and naive bot blocks — and returns the
full page as clean, ad-stripped Markdown, not a summary. Plus web search that
returns real links. Zero dependencies: pure Python standard library.
AI agents constantly hit pages their built-in tools can't read. NetLens fixes the three usual reasons a fetch comes back empty or useless:
Native web tools | NetLens |
Honor | Reads like the browser you'd open yourself — doesn't consult |
Blocked by header/User-Agent bot filters ( | Sends real browser headers via the system |
Return a summary of the page | Returns the full page content as Markdown |
Leave ads, cookie banners, nav, and related-links chrome in the output | Strips boilerplate locally so only the content reaches your context |
It does not try to defeat JavaScript/Cloudflare challenge pages or CAPTCHAs — that's out of scope by design. When a page is a hard block, the HTTP status is surfaced honestly rather than faked.
Related MCP server: Scrapi MCP Server
npm (via npx):
{
"mcpServers": {
"netlens": {
"command": "npx",
"args": ["-y", "netlens-mcp"]
}
}
}PyPI (via uvx):
{
"mcpServers": {
"netlens": {
"command": "uvx",
"args": ["netlens-mcp"]
}
}
}Add either to your MCP client config (e.g. .mcp.json for Claude Code), then
restart the session so the tools load.
web_searchSearch the web and return real result links (title, URL, snippet), parsed locally —
links, not summaries. Follow up with web_fetch to read a result.
Argument | Type | Description |
| string (required) | The search query |
| integer | Optional cap; default returns the full first page (~10) |
| string |
|
| integer | Result page, 1-based. SearXNG only |
| string |
|
| string | e.g. |
The result reports which engine answered and what happened to any that were skipped, so falling through to a different backend is visible rather than silent:
{
"query": "…",
"engine": "mojeek",
"results": [ … ],
"engines_skipped": [ { "engine": "duckduckgo", "outcome": "HTTP 202" } ]
}Outcomes are observations, not conclusions — HTTP 202 is what the server sent;
whether that is throttling, changed markup or genuinely no matches cannot be
determined from the response. With SearXNG configured, direct answers,
infoboxes and suggestions appear alongside the results.
A search fetches a single result page (~10 results), returned in full by default so nothing at position 9/10 is dropped. There's no deep pagination — if the answer isn't in the first page, refine the query.
web_fetchFetch any page and return its full content as clean Markdown.
Argument | Type | Description |
| string (required) | URL to fetch (scheme optional; |
| string |
|
| string | Return only this heading's content, plus anything nested under it |
| string |
|
| integer | Optional cap on returned characters (truncates with a note) |
A large article can be tens of thousands of characters when you want one part of
it. mode="outline" returns its shape, and section returns just that piece —
on a large encyclopedia article that is 153,000 characters full, 1,000 as an
outline, and 7,400 for the section actually wanted.
web_fetch(url=…, mode="outline") → headings with each section's size
web_fetch(url=…, section="Gameplay") → that section and its subsectionsOn link-heavy pages the URLs themselves are a large share of the output — around 40%
of a big encyclopedia article — so links="none" roughly halves it when you only need
the prose. Links pointing back into the same page are always rendered as plain text.
If a page turns out to be a client-rendered shell, web_fetch says so rather than
returning an empty result as a success:
(note: Only 10 characters of readable text were found in 6,856 characters of HTML. This page appears to be rendered client-side by JavaScript…)
Workflow: web_search to find pages, then web_fetch to read them.
Search is a pluggable, selectable registry. In auto mode NetLens tries engines in
order and returns the first with results, so a rate-limit/challenge page on one
falls through to the next.
Engine | Notes |
| Default; |
| Automatic fallback |
| Independent index; automatic fallback |
| Self-hosted/public SearXNG JSON API — set |
Pick per call with the engine argument, or set a default with
NETLENS_SEARCH_ENGINE.
Environment Variable | Default | Description |
|
| Default search backend |
| — | SearXNG base URL, e.g. |
|
| Seconds before an unreachable SearXNG is skipped |
| Chrome UA | Override the request User-Agent |
|
| Cap on a single response; larger ones are truncated |
|
| Seconds to reuse a fetched page; |
|
| Minimum seconds between requests to the same host |
|
| Ceiling on a single tool call |
Point NETLENS_SEARXNG_URL at an instance with the JSON API enabled (search.formats
must include json in its settings.yml). It is then tried first in auto mode,
which removes the HTML scraping — and the rate limiting that comes with it — from the
common path.
Because it is tried first, it must fail fast when the box is off: the connect timeout is bounded separately so an unreachable instance is skipped in a few seconds rather than stalling every search, and the skip is reported in the result.
Direct fetch. Requests go straight to the target site via the system curl
(better TLS/HTTP-2/compression, so it looks like a real browser), falling back to
urllib. No third-party proxy or reader is involved.
Local conversion. HTML → Markdown happens in-process with a hand-rolled
html.parser converter — headings, lists, links (relative URLs resolved), code
blocks, and GFM tables with colspan/rowspan.
Content selection, not deletion. NetLens picks the page's main content region
— the HTML5 landmark (<main> / <article> / [role=main]) when one exists,
otherwise the subtree holding the most prose relative to its link density — and
converts only that. Because it selects a winner rather than deleting anything
that matches a name pattern, extraction cannot silently return an empty page.
Nothing inspects CSS class or id names to decide what is content.
Pruning by measurement. Within that region, blocks that are overwhelmingly
link anchors (navboxes, tag clouds, "more from this site" grids) are dropped
based on their link density. Non-rendering elements (<script>, <style>, …),
explicitly hidden elements, and third-party ad-network slots (identified by
vendor names like adsbygoogle, which cannot collide with real prose) are
removed outright.
Response charset is honored (from Content-Type or <meta>), so non-UTF-8
pages don't come back garbled.
The server is also a plain script — handy for testing before a client loads it:
python -m netlens_mcp.server search "http caching best practices"
python -m netlens_mcp.server fetch https://example.com/article
python -m netlens_mcp.server full https://example.com # whole body
python -m netlens_mcp.server raw https://example.com # unconverted HTMLpython -m netlens_mcp runs the stdio MCP server; python -m netlens_mcp.server <cmd> runs the CLI.
pip install -e ".[dev]"
python -m pytest # run the test suite
ruff check . # lintPython 3.10+ (and the system curl, which ships with modern Windows/macOS/Linux;
falls back to urllib if absent)
Fetch ANY web page directly and return its FULL content as clean Markdown (not a summary). Uses browser-like headers to get past common bot filters that block naive/robots-respecting clients (e.g. 403/202 to non-browser clients). Requests go straight to the target site; HTML is converted to Markdown locally (no third-party proxy/reader). Content is found by selecting the page's main content region and pruning navigation rails, so surrounding chrome is left out without ever risking the article. mode='article' (default) returns that region; mode='full' keeps the whole page body; mode='raw' returns unconverted HTML. Does NOT solve full JS/Cloudflare challenge pages or CAPTCHAs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch (scheme optional; https assumed) | |
| mode | No | article=main content only (default), full=whole body, raw=unconverted HTML, outline=heading structure with each section's size, for deciding what to request | |
| links | No | inline (default) keeps Markdown link targets; 'none' keeps link text but drops the URLs, which cuts a large share of the output on link-heavy pages | |
| section | No | Return only the section with this heading, plus anything nested under it. Matched case-insensitively on a substring. Use mode='outline' first to see what a long page contains. | |
| max_chars | No | Optional cap on returned characters (truncates with a note); omit for full content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral traits not covered by annotations: uses browser-like headers, converts HTML to Markdown locally, selects main content region, and explains modes. No contradiction with 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 well-structured and information-dense, starting with the core purpose and then detailing modes and limitations. It could be slightly more concise, but each sentence adds value.
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 5 parameters and no output schema, the description covers all aspects: modes, parameter behavior, limitations, and use cases. It is thorough enough for an AI agent to use correctly.
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?
While the input schema describes all parameters, the description adds context such as default modes, the purpose of each mode, and the interplay between parameters (e.g., using 'outline' before 'section'). This enhances understanding beyond the schema.
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 tool fetches any web page and returns full content as clean Markdown, distinguishing it from the sibling 'web_search' which likely returns search results.
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 explains when to use the tool (fetching full pages, bypassing bot filters) and its limitations (cannot solve JS/Cloudflare challenges or CAPTCHAs). However, it does not explicitly compare to the sibling tool 'web_search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web and return real result links (title, URL, snippet), parsed locally from a search engine's HTML endpoint via a direct, bot-bypassing fetch. Returns LINKS, not summaries — follow up with web_fetch to read a result's full content. Returns the full first page of results (~10); a search fetches one page, so refine the query rather than expecting deep pagination. WORKFLOW: web_search to find pages, then web_fetch to read them.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Result page, 1-based. SearXNG only — the scraped engines serve one page and are reported as not supporting this rather than ignoring it. | |
| limit | No | Optional cap on results; default returns the full first page (~10) | |
| query | Yes | The search query | |
| engine | No | Search backend. 'auto' (default) tries SearXNG first when configured, then DuckDuckGo, Mojeek, Bing. 'searxng' needs NETLENS_SEARXNG_URL. | |
| categories | No | SearXNG category filter, e.g. 'it', 'science', 'news'. SearXNG only. | |
| time_range | No | Restrict to recent results. SearXNG only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds significant behavioral context: parsing from HTML endpoints, bot-bypassing, returning one page of ~10 results, and engine fallback behavior. No contradictions.
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 concise and well-structured: purpose first, then output type, then limitations, then workflow. Every sentence adds value, and the length is appropriate for the tool's complexity.
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 (6 parameters, 100% schema coverage, no output schema, annotations present), the description covers all key aspects: return format, pagination limits, engine behavior, and workflow. It is complete for the 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 coverage is 100%, so baseline is 3. The description does not add new parameter semantic details beyond what the schema provides, though it does explain engine behavior and page limitations implicitly. No additional value beyond schema.
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 searches the web and returns links (title, URL, snippet). It distinguishes from the sibling tool web_fetch by specifying that it returns links not summaries, and explicitly recommends following up with web_fetch for full content.
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 explicit guidance: use web_search to find pages, then web_fetch to read them. It also warns against expecting deep pagination and suggests refining the query. However, it does not explicitly state when not to use it or list alternative tools beyond web_fetch.
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.
v0.2.3web_fetchweb_searchweb_search and web_fetch have clearly distinct purposes: one finds relevant URLs via search, the other retrieves full page content. The descriptions explicitly differentiate them and explain their complementary workflow, eliminating any ambiguity.
Both tools follow the consistent verb_noun pattern (web_search, web_fetch), making the naming predictable and easy to understand.
Only 2 tools is minimal, but for a narrow focus on web searching and fetching, it's plausible. However, it feels slightly thin for a general-purpose server, as many use cases might require additional tools.
The tool surface covers only search and fetch, lacking tools for pagination, saving results, or handling multiple search engines. This leaves obvious gaps for a comprehensive web research workflow, potentially causing agent failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server (stdio): fetch web pages as clean readable markdown via the AgentForge API
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.
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pzalutski-pixel/netlens-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
