mcp-webgate
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., "@mcp-webgatefetch https://example.com/article"
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-webgate
Web search that doesn't wreck your AI's memory.
mcp-webgate is an MCP server that gives your AI clean, bounded web content โ across all major AI clients:
IDEs: Claude Desktop, Claude Code, Zed, Cursor, Windsurf, VSCode
CLI Agents: Gemini CLI, Claude CLI, custom agents
๐ฑ A Gentle Introduction
What is mcp-webgate? When your AI uses a standard "fetch URL" tool, it gets the raw HTML of the page โ ads, menus, scripts, cookie banners and all. A single news article can dump 200,000 tokens of garbage into the AI's memory, wiping out your entire conversation.
mcp-webgate is a protective filter that sits between your AI and the web:
Strips the junk โ menus, scripts, ads, footers are removed with surgical HTML parsing; only readable text passes through
Hard-caps every response โ no page can ever blow up your context window, no matter how big the original was
Optionally summarizes โ route results through a secondary local LLM that produces a compact Markdown report with citations; your primary AI gets a polished briefing instead of a wall of text
The result: clean, bounded, useful web content โ always.
๐ฌ Real example: what happens under the hood
Searching for "mcp model context protocol" with LLM features on:
Query โ LLM expands to 5 search variants โ 20 pages found, 13 fetched in parallel
Raw HTML downloaded 5.16 MB (~1,290,000 tokens)
After cleaning 52.1 KB ( ~13,000 tokens) โ 99% noise stripped
After LLM summary 5.8 KB ( ~1,450 tokens) โ structured report with citations13 sources distilled into ~1,450 tokens. A single naive fetch of just one of those pages (e.g. a security blog at 563 KB) would dump ~140,000 tokens of raw HTML into your AI's context. webgate processes all 13 and delivers a clean briefing that fits in a footnote.
This is an intensive case (5 queries ร 5 results). A typical search with 3โ5 results still saves 95%+ of context compared to raw fetching โ and your AI gets structured, ranked content instead of a wall of HTML soup.
Related MCP server: Fetch as Markdown
๐ Quick Start
1. Make sure you have uvx
pip install uvuvx runs Python tools without installing them permanently. You only need to do this once.
2. Set up a search backend
The easiest option is SearXNG โ free, no account, runs locally:
docker run -d -p 8080:8080 --name searxng searxng/searxngNo Docker? Use a cloud backend instead (Brave, Tavily, Exa, SerpAPI) โ see Backends.
3. Add webgate to your AI client
See the Integrations table for your specific client. As a quick example, for Claude Desktop:
Open the config file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Add this:
{
"mcpServers": {
"webgate": {
"command": "uvx",
"args": ["mcp-webgate"],
"env": {
"WEBGATE_DEFAULT_BACKEND": "searxng",
"WEBGATE_SEARXNG_URL": "http://localhost:8080"
}
}
}
}Restart the client after editing.
4. Ask your AI to search!
Search the web for: latest news on AI regulationThe AI will use webgate_query automatically. You're done.
๐ How it works
Your question
โ
Search backend (SearXNG / Brave / Tavily / Exa / SerpAPI)
โ [deduplicate URLs, block binary files, filter domains]
Fetch pages in parallel (streaming โ hard size cap per page)
โ [optional: retry failed pages from reserve pool]
Strip HTML junk (menus, ads, scripts, footers โ lxml)
โ
Clean up text (invisible chars, unicode junk, BiDi tricks)
โ
BM25 reranking (best-matching results first โ always active)
โ [optional: LLM reranking]
Cap total output to budget
โ [optional: LLM summarization โ compact Markdown report]
Clean result lands in your AI's context๐ ๏ธ Tools
webgate gives your AI three tools:
webgate_fetch โ read a single page
Use this when you already know the URL you want. The AI passes the URL and gets back the cleaned text โ up to max_query_budget characters (default 32,000).
{ "url": "https://example.com/article", "max_chars": 32000 }{
"url": "https://example.com/article",
"title": "Article Title",
"text": "cleaned text...",
"truncated": true,
"char_count": 12450
}webgate_query โ search + fetch + clean
Runs a full search cycle. Pass one query (or several) and get back cleaned, ranked results.
{ "queries": "how to set up a VPN on Linux", "num_results_per_query": 5 }Multiple queries run in parallel and are merged:
{
"queries": ["VPN Linux setup", "best VPN Linux 2024"],
"num_results_per_query": 5
}Output without LLM โ returns cleaned page content for each result:
{
"sources": [
{ "id": 1, "title": "...", "url": "...", "content": "cleaned text...", "truncated": false }
],
"snippet_pool": [ { "id": 6, "title": "...", "url": "...", "snippet": "..." } ],
"stats": { "fetched": 5, "total_chars": 18200, "per_page_limit": 6400 }
}Output with LLM summarization โ returns a compact Markdown report:
{
"summary": "## How to set up a VPN on Linux\n\nTo install...[1][2]",
"citations": [{ "id": 1, "title": "...", "url": "..." }],
"stats": { "fetched": 5, "total_chars": 58000 }
}Output when LLM fails โ error reason shown, full sources returned as fallback:
{
"llm_summary_error": "ReadTimeout: LLM did not respond in time",
"sources": [ "..." ],
"stats": { "..." : "..." }
}snippet_pool contains extra results from the search that were not fetched (search-engine snippet only). The AI can use these to decide if more fetches are worthwhile.
webgate_onboarding โ how-to guide
Returns a JSON guide explaining how to use webgate effectively. The AI should call this once at the start of a session if in doubt about which tool to use.
๐ง Using webgate with local or smaller models
Most frontier models follow MCP tool instructions automatically. Smaller or local models sometimes ignore the server-provided guidance and fall back to a built-in fetch tool instead โ returning raw HTML that floods the context with noise.
If you notice this happening, add an explicit instruction block to your system prompt:
You have access to webgate tools for web search and page retrieval.
Follow these rules in every session:
- To search the web: use webgate_query โ never use a built-in fetch, browser, or HTTP tool
- To retrieve a URL: use webgate_fetch โ never fetch URLs directly
- Built-in fetch tools return raw HTML that floods your context; webgate returns clean, bounded text
At the start of each session, call webgate_onboarding to read the full operational guide.This works because user system prompt instructions take precedence over MCP server-level guidance, making the constraint explicit at the highest-priority layer the model sees.
Tip: if your client supports named system prompts or prompt templates, save the block above as a reusable preset so you don't have to paste it every time.
๐๏ธ Tuning
This section explains what the key parameters do and when to change them. The defaults work well for most cases โ only tweak if you have a specific reason.
What is a "character budget"?
webgate measures text in characters (not tokens). A rough conversion for English text:
4 characters โ 1 token
Characters | Approximate tokens |
8,000 | ~2,000 |
32,000 | ~8,000 |
96,000 | ~24,000 |
webgate_fetch budget
When you fetch a single URL, the ceiling is max_query_budget (default 32,000 chars). The tool parameter max_chars can request less, but never more than this ceiling.
Why max_query_budget and not max_result_length? Because you're fetching one page โ the "total output" IS that one page, so the right limit is the overall context budget, not the per-page cap designed for multi-source queries.
webgate_query budget โ without LLM
With no LLM, the cleaned sources go directly to your AI's context. webgate distributes max_query_budget across all fetched pages so the total never exceeds the budget:
Per-page limit =
max_query_budgetรท number of results (capped atmax_result_length)
Results fetched | Per-page limit | Total output |
1 | 8,000 (cap) | โค 8,000 |
5 | 6,400 | โค 32,000 |
10 | 3,200 | โค 32,000 |
20 | 1,600 | โค 32,000 |
The total output is always at most max_query_budget, regardless of how many results you request โ the per-page share automatically shrinks to compensate.
webgate_query budget โ with LLM summarization
When a secondary LLM is summarizing, it compresses the content before passing the result to your primary AI. This means it's safe โ and beneficial โ to give it more raw material to work from.
webgate scales up the input using input_budget_factor (default 3):
LLM input budget =
max_query_budgetรinput_budget_factorDefault: 32,000 ร 3 = 96,000 chars
Results fetched | LLM input / page | Total LLM input | Output to your AI |
1 | 96,000 | 96,000 | compact report |
5 | 19,200 | 96,000 | compact report |
10 | 9,600 | 96,000 | compact report |
20 | 4,800 | 96,000 | compact report |
The secondary LLM sees much more content per page. Your primary AI sees only the final report โ typically 1,000โ3,000 tokens โ regardless of how many sources were processed. This is the main efficiency advantage of LLM mode.
Quick tuning guide
Symptom | Fix |
AI responses feel slow, too much text | Reduce |
AI answers are shallow or miss details | Increase |
LLM summary is thin or misses things | Increase |
LLM summary times out or is very slow | Reduce |
| Increase |
Pages are slow to download | Reduce |
Server downloads too much garbage | Reduce |
๐ค LLM Features
Optional, opt-in. When llm.enabled = false (the default), webgate is fully deterministic. Enable the [llm] block to unlock three extra capabilities.
๐ค When to enable LLM features
Situation | Recommended setup | Typical latency overhead |
Fast answers, general research | LLM disabled (default) โ BM25-ranked clean sources, zero latency overhead | none |
Deep research on a complex topic | Summarization on โ get a cited Markdown report instead of raw pages | +5โ30s |
Broad topic, one query isn't enough | Expansion + Summarization โ LLM generates variants and synthesizes all results | +6โ35s |
Result order matters more than speed | LLM reranking on โ semantic ordering at the cost of one extra LLM call per query | +1โ5s |
Privacy: with LLM disabled, no data leaves your machine except web requests. With LLM enabled, cleaned search results (not raw HTML) are sent to the configured base_url. Point it at a local Ollama instance to keep everything on-device.
Latency trade-off: each enabled feature adds one LLM round-trip per query. Expansion adds ~1โ5s; summarization adds ~5โ30s depending on model and content volume. For interactive use, summarization with a fast local model (e.g. Gemma 3 4B) is a good starting point.
Setup
[llm]
enabled = true
base_url = "http://localhost:11434/v1" # Ollama, OpenAI, LM Studio, vLLM, Groq...
api_key = "" # empty for local models
model = "gemma3:27b"
timeout = 60 # local 27B+ models may need up to 60sOr with env vars:
"env": {
"WEBGATE_LLM_ENABLED": "true",
"WEBGATE_LLM_BASE_URL": "http://localhost:11434/v1",
"WEBGATE_LLM_MODEL": "gemma3:27b",
"WEBGATE_LLM_TIMEOUT": "60"
}base_url accepts any OpenAI-compatible endpoint: OpenAI, Ollama, LM Studio, vLLM, Together AI, Groq, and others.
Query expansion
When you send a single query and expansion_enabled = true, the LLM automatically generates complementary search variants before hitting the backend. If you already pass multiple queries, this step is skipped.
"best laptop for programming"
โ expansion
["best laptop for programming 2024", "developer laptop recommendations", "laptop specs for coding"]
โ all search in parallelFalls back silently to your original query if the LLM fails.
Summarization
When summarization_enabled = true, the LLM reads all fetched pages and writes a structured Markdown report with inline citations. Your AI receives the report instead of the raw text.
Success:
summary+citations(lean output โ no raw content passed to your AI)Failure:
llm_summary_errorwith the reason + fullsourcesas fallback (your AI can still work with the cleaned content)
The report length target is max_summary_words. When 0 (default), it is derived from max_query_budget / 5 โ e.g. with a 32k budget, the target is ~6,400 words.
Reranking
Results are always reranked by BM25 (keyword overlap, zero cost) before being returned. Optionally, the LLM can do a second pass for semantic relevance:
Tier | When | Cost |
BM25 (deterministic) | Always | Zero โ pure math |
LLM-assisted |
| One LLM call per query |
LLM reranking adds latency proportional to your LLM response time. Enable it only if result ordering matters more than speed.
Pipeline: clean โ BM25 rerank โ (LLM rerank) โ (LLM summarize) โ output
๐ Integrations
mcp-webgate works with all major AI clients:
Platform | Configuration Guide | Notes |
Claude Desktop | Desktop application | |
Claude Code | CLI coding agent | |
Zed Editor | Native MCP support | |
Cursor | Requires Agent mode | |
Windsurf | Global config only | |
VSCode | Via Copilot or MCP extension | |
Gemini CLI | Google's CLI agent | |
Claude CLI | Anthropic's CLI agent |
๐ฆ Installation
Via uvx (recommended โ no install needed)
uvx mcp-webgateVia pip / uv
pip install mcp-webgate
# or
uv add mcp-webgateโ๏ธ Full Configuration
Ready-to-use config files are in examples/.
Resolution order
CLI args > env vars > webgate.toml > defaultsConfig is read once at startup; restart the server to apply changes.
You can configure webgate in three ways โ mix and match as needed:
webgate.tomlโ checked at startup in./webgate.tomlthen~/webgate.tomlEnv vars โ
WEBGATE_*prefix, always strings (MCP JSON requirement)CLI args โ
--kebab-case, integers stay integers, ideal for multi-instance setups
Config file (webgate.toml)
[server]
max_download_mb = 1 # how many MB to download per page before cutting off
max_result_length = 8000 # max chars per page in multi-source queries (no LLM)
max_query_budget = 32000 # total char budget for a fetch, or input pool for a query
max_search_queries = 5 # max parallel queries per call
results_per_query = 5 # results to fetch per query
search_timeout = 8 # seconds before giving up on a page
oversampling_factor = 2 # fetch 2ร more candidates than needed (dedup reserve)
auto_recovery_fetch = false # retry failed fetches from reserve pool
max_total_results = 20 # hard cap: never fetch more than this many pages total
blocked_domains = ["reddit.com", "pinterest.com"]
allowed_domains = [] # if non-empty, only these domains are allowed
adaptive_budget = false # [EXPERIMENTAL] proportional char allocation based on BM25 rank
adaptive_budget_fetch_factor = 3 # generous pre-rank fetch multiplier
[backends]
default = "searxng"
[backends.searxng]
url = "http://localhost:8080"
[backends.brave]
api_key = "BSA..."
[backends.tavily]
api_key = "tvly-..."
search_depth = "basic"
[llm]
enabled = true
base_url = "http://localhost:11434/v1"
api_key = ""
model = "llama3.2"
timeout = 60
expansion_enabled = true
summarization_enabled = true
llm_rerank_enabled = false
max_summary_words = 0 # 0 = max_query_budget / 5 (e.g. 6400 with budget 32000)
input_budget_factor = 3 # LLM input = max_query_budget ร factor (default: 96000)MCP client config examples
With env vars (all values must be strings):
{
"mcpServers": {
"webgate": {
"command": "uvx",
"args": ["mcp-webgate"],
"env": {
"WEBGATE_DEFAULT_BACKEND": "searxng",
"WEBGATE_SEARXNG_URL": "http://localhost:8080",
"WEBGATE_LLM_ENABLED": "true",
"WEBGATE_LLM_TIMEOUT": "60"
}
}
}
}With CLI args (integers stay integers โ ideal for running independent instances in Zed, Cursor, etc.):
{
"mcpServers": {
"webgate": {
"command": "uvx",
"args": [
"mcp-webgate",
"--searxng-url", "http://localhost:8080",
"--llm-enabled",
"--llm-model", "gemma3:27b",
"--llm-timeout", "60"
]
}
}
}Boolean flags support --flag / --no-flag syntax (e.g. --llm-enabled, --no-llm-rerank-enabled).
Full reference
CLI argument | Env var | Default | Description |
|
|
| Active backend |
|
|
| SearXNG instance URL |
|
| (empty) | Brave Search API key |
|
| (empty) | Tavily API key |
|
| (empty) | Exa API key |
|
| (empty) | SerpAPI key |
|
|
| SerpAPI engine ( |
|
|
| SerpAPI country code |
|
|
| SerpAPI language |
|
|
| Per-page download size cap (MB) |
|
|
| Per-page char cap (no-LLM queries) |
|
|
| Total char budget for fetch and query |
|
|
| Max queries per call |
|
|
| Default results fetched per query |
|
|
| HTTP request timeout (seconds) |
|
|
| Search result multiplier for dedup reserve |
|
|
| Enable gap-filler (Round 2 fetch) |
|
|
| Hard cap on total results per call |
|
|
| Enable structured debug logging |
|
| (empty) | Log file path (empty = stderr) |
|
|
| Include content in summarized citations; also activates debug logging |
|
|
| [EXPERIMENTAL] Proportional char allocation based on BM25 rank |
|
|
| [EXPERIMENTAL] Generous pre-rank fetch multiplier |
|
|
| Enable LLM features |
|
|
| OpenAI-compatible endpoint |
|
| (empty) | API key (empty for local models) |
|
|
| Model name |
|
|
| LLM request timeout (seconds) |
|
|
| Auto-expand queries into variants |
|
|
| LLM summary with citations |
|
|
| LLM-assisted reranking |
|
|
| Summary word target (0 = auto) |
|
|
| LLM input budget multiplier |
๐ Backends
Backend | Auth | Notes |
SearXNG | none | Self-hosted, recommended |
Brave Search | API key | High quality, free tier available |
Tavily | API key | AI-oriented snippets, free tier available |
Exa | API key | Neural/semantic search, free tier available |
SerpAPI | API key | Proxy for Google, Bing, DuckDuckGo and more, free tier available |
SearXNG quickstart (Docker)
docker run -d -p 8080:8080 --name searxng searxng/searxngThen set WEBGATE_SEARXNG_URL=http://localhost:8080.
Exa notes
Exa uses neural (semantic) search by default โ the primary reason to use it over keyword backends. use_autoprompt is hardcoded to false (not user-configurable) because mcp-webgate handles query expansion via its own LLM expander.
SerpAPI notes
engine selects the underlying search engine (google, bing, duckduckgo, yandex, yahoo). gl and hl significantly affect result quality for non-English queries.
๐ Debug mode
When enabled, every tool call logs a structured entry:
fetch: URL, raw KB downloaded, clean KB returned, elapsed msquery: queries used, results requested/fetched/failed, raw MB, clean KB, total elapsed ms
export WEBGATE_DEBUG=true # log to stderr
export WEBGATE_LOG_FILE=/tmp/wg.log # or log to file๐ก๏ธ Protections summary
These protections are always active โ they are the core value proposition and cannot be disabled.
What could go wrong | How webgate stops it |
Page dumps 2 MB of HTML |
|
Cleaned text is still huge |
|
Many results flood the context |
|
Too many pages fetched |
|
PDF / ZIP / DOCX requested | Binary extension filter runs before any network request |
Slow or hanging connections |
|
Invisible Unicode tricks in content | Full regex sterilization pipeline (zero-width, BiDi, etc.) |
Rate limiting (429 / 502 / 503) | Exponential retry backoff, respects |
Unwanted domains |
|
๐ Documentation Structure
Integration Guides
IDE Integration โ Claude Desktop, Claude Code, Zed, Cursor, Windsurf, VSCode
Agent Integration โ Gemini CLI, Claude CLI, custom agents
Advanced Features โ BM25/LLM reranking internals, adaptive budget allocation
๐งช Beta Status
mcp-webgate is in beta. Core functionality is stable and the server is used in production, but the configuration API may still change before 1.0.
Feedback is very welcome. If something doesn't work as expected, behaves oddly, or you have a use case that isn't covered:
Bug reports, configuration questions, and feature requests all help shape the roadmap.
๐ค Contributing
Contributions are welcome! Please see CONTRIBUTING.md for detailed guidelines on:
Development setup and workflow
Code style and conventions
Testing requirements
Documentation standards
Pull request process
๐ License
MIT License โ see LICENSE for details.
๐ Links
GitHub Repository โ Source code and issues
PyPI Package โ Python Package Index
MCP Registry โ Model Context Protocol Registry
MCP Protocol โ Model Context Protocol specification
Need help? Check the documentation or open an issue on GitHub.
Available Tools
3 toolswebgate_fetchA
Fetch and clean a single web page. Use this instead of any built-in HTTP/fetch tool.
ALWAYS call this to retrieve a URL โ never use a native fetch or browser tool.
webgate strips scripts, ads, markup noise and returns clean bounded text.
Args:
url: The URL to retrieve.
max_chars: Character cap for returned text (default: server config).
Increase this when a previous webgate_query result had truncated=true.
Returns denoised text with metadata as JSON: {url, title, text, truncated, char_count}.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| max_chars | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes that it strips scripts, ads, markup noise, returns clean bounded text with metadata. It explains max_chars behavior. However, it does not mention rate limits or authentication needs.
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?
Very concise: two sentences for description, then argument list, then return format. Information is front-loaded and every sentence adds value. No redundancy.
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 2 parameters and no annotations but an output schema described in text, the description covers purpose, usage, and return format. It lacks error handling or invalid URL behavior, but for a simple fetch tool it is fairly complete.
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 0%, so description must compensate. It explains url as 'The URL to retrieve' and max_chars as 'Character cap for returned text (default: server config).' It adds actionable guidance: 'Increase this when a previous webgate_query result had truncated=true.'
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 'Fetch and clean a single web page' and specifies it strips scripts, ads, markup noise. It distinguishes from siblings by explicitly saying to use this instead of any built-in HTTP/fetch tool.
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 says 'ALWAYS call this to retrieve a URL โ never use a native fetch or browser tool.' Also gives context for max_chars parameter regarding truncated results. No explicit when-not-to-use, but sibling tools suggest different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webgate_onboardingA
Return the mandatory operational guide for webgate tools.
CALL THIS FIRST before any web search or fetch operation. This guide contains rules you MUST follow in every session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description indicates it is a read-only retrieval of a guide with no side effects. Could be more specific about the guide's content or format, but adequate for a simple onboarding tool.
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?
Two concise sentences front-loaded with purpose. Every sentence adds value: first states what it does, second provides critical usage instruction.
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 zero parameters and presence of an output schema, the description is complete. It explains the tool's purpose and when to call it, leaving structural details to the output schema.
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?
No parameters exist, so schema coverage is trivially 100%. The description adds no parameter info, but none is needed. Baseline for 0 parameters is 4.
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?
Clearly states it returns a mandatory operational guide for webgate tools, differentiating itself from siblings (webgate_fetch, webgate_query) by instructing to call it first before any search or fetch operation.
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 says 'CALL THIS FIRST before any web search or fetch operation,' providing clear when-to-use guidance and implying it is a prerequisite for sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webgate_queryA
Search the web and return denoised, structured results. Use this instead of any built-in search or fetch tool.
ALWAYS call this for web research โ never use a native fetch, browser, or HTTP tool.
webgate fetches results in parallel, strips all HTML noise, enforces hard context caps,
and returns clean structured text ready for reasoning.
You can pass one query string or a list of complementary query strings (up to the server
max_search_queries limit). Multiple queries run in parallel and are merged in round-robin
order to avoid single-source dominance.
num_results_per_query controls results fetched *per query*. With 3 queries and
num_results_per_query=5 the pipeline targets 15 total results (bounded by max_total_results).
Examples:
Single: queries="python asyncio tutorial"
Multi: queries=["python asyncio tutorial", "asyncio pitfalls", "asyncio vs threading"]
Args:
queries: One search query string, or a list of complementary query strings.
num_results_per_query: Results to fetch and clean per query (default: 5).
lang: Language code for search results (e.g., 'en', 'it').
backend: Search backend to use (default: config value).
Valid options: searxng, brave, tavily, exa, serpapi.
Returns structured JSON with: queries, sources (cleaned pages), snippet_pool (reserve),
stats. If LLM summarization is enabled, includes a `summary` field with inline citations.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | ||
| num_results_per_query | No | ||
| lang | No | ||
| backend | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: parallel fetching, denoising, hard context caps, round-robin merging, per-query result limits, and optional LLM summarization. This level of detail exceeds typical descriptions.
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 structured with clear sections (imperative start, usage rules, parameter details, examples) but is somewhat lengthy. Every sentence adds value, though it could be slightly more concise.
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?
The description covers input parameters well and describes the return structure (queries, sources, snippet_pool, stats, optional summary). However, no formal output schema is provided despite the context indicating one exists, leaving some detail unspecified.
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 0%, so the description must compensate. It thoroughly explains 'queries' (single or list), 'num_results_per_query' (per-query default), 'lang' (language code), and 'backend' (valid options listed). Examples illustrate usage effectively.
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 that the tool searches the web and returns 'denoised, structured results'. It explicitly distinguishes from built-in tools by instructing to 'never use a native fetch, browser, or HTTP tool', establishing a unique purpose for web research.
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 strongly advises using this for web research over native tools, and explains scenarios for single vs. multiple queries. However, it does not explicitly differentiate from its sibling 'webgate_fetch' or provide when-not-to-use context.
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.
3 tool updates
v0.1.33- First observed
webgate_fetch - First observed
webgate_onboarding - First observed
webgate_query
TDQS
Each tool has a clearly distinct purpose: webgate_fetch retrieves a single page, webgate_query performs web searches, and webgate_onboarding provides mandatory instructions. There is no overlap or ambiguity between them.
All tools follow a consistent 'webgate_' prefix with a descriptive suffix (fetch, onboarding, query). The naming pattern is uniform and predictable.
With 3 tools, the server is scoped appropriately for its purpose: web search, page fetching, and an onboarding guide. The count feels neither too sparse nor excessive.
The tool surface covers the core operations: searching the web, fetching a single page, and providing operational guidance. There are no obvious gaps given the server's stated purpose.
Maintenance
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
Clean Markdown and AI-readability scoring for any URL. Built for AI agents.
11URL to clean markdown for LLMs: a polite, robots.txt-respecting web reader. Free, no API key
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Related MCP Servers
- AlicenseBqualityFmaintenanceEnables retrieval and processing of web page content for LLMs by converting HTML to markdown, with support for content truncation and pagination.13MIT
- FlicenseNot gradedqualityDmaintenanceFetches web pages and converts them to clean, readable markdown format by extracting main content while removing navigation, ads, and other non-essential elements to minimize token usage.4-
- AlicenseAqualityAmaintenanceShrink the web for your local LLMs! Provides web research capabilities to low resource models and environments.1226MIT
- FlicenseAqualityCmaintenanceReduces token consumption by 73-87% by cleaning web and API data before it reaches the LLM context window. Supports fetching URLs, searching the web, optimizing JSON, and more.61-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/x-hannibal/mcp-webgate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server