Provides web search capabilities using the Brave Search API.
Offers fallback web search using DuckDuckGo (DDG/DDGS).
Includes old.reddit fallback for fetching Reddit pages with improved compatibility.
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., "@AtlasForge-WebProxy search for SpaceX Starship updates"
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.
Self-hosted web search/fetch proxy plus stdio MCP server for AI agents. It provides Brave-backed search, page fetch with retries and browser-like user-agent fallback, old.reddit hardening, response caching, paper PDF fetch, image search/download, and SSRF guards.
./install.sh
mkdir -p "${XDG_CONFIG_HOME:-$HOME/.config}/atlasforge-webproxy"
$EDITOR "${XDG_CONFIG_HOME:-$HOME/.config}/atlasforge-webproxy/config.env"
chmod 600 "${XDG_CONFIG_HOME:-$HOME/.config}/atlasforge-webproxy/config.env"Set BRAVE_API_KEY in that file. Get a key at
https://brave.com/search/api/. Without a key, the proxy falls back to DDG/DDGS
where available.
Run directly:
.venv/bin/python -m atlasforge_webproxy.service --host 127.0.0.1 --port 8765
curl http://127.0.0.1:8765/healthWire MCP into a client:
{
"mcpServers": {
"atlasforge-web-proxy": {
"command": "/path/to/AtlasForge-WebProxy/.venv/bin/python",
"args": ["-m", "atlasforge_webproxy.mcp_server"],
"env": {}
}
}
}Related MCP server: Web Search MCP Server
Priority: environment variables, then
${XDG_CONFIG_HOME:-~/.config}/atlasforge-webproxy/config.env, then defaults.
For migration, ~/.config/atlasforge/web-proxy.env is read only when the new
file does not exist, and a deprecation warning is logged.
Setting | Default | Purpose |
| empty | Brave Search API key. |
|
| Flask bind host. |
|
| Flask bind port. |
| host/port above | MCP/client target URL. |
| XDG cache | Search/fetch/image cache. |
| XDG cache | Paper PDF/text artifacts. |
|
|
|
|
| Service outbound timeout. |
|
| Python client timeout. |
|
| MCP-to-service timeout. |
|
| Search cache TTL. |
|
| Page fetch cache TTL. |
|
| Paper fetch cache TTL. |
|
| Fetch retry attempts. |
|
| Retry base delay. |
|
| Max |
|
| Enable retry jitter. |
|
| Retry 403 with browser UA. |
|
| Try old.reddit fallback. |
|
| Legacy DNS fail-open mode. |
|
| Optional AtlasForge JSON mirroring. |
|
| Optional AtlasForge stage tools. |
See config.env.example for the full list, including user-agent and size-limit
knobs.
./install.sh creates .venv, installs the package, copies
config.env.example if no config exists, installs
~/.config/systemd/user/atlasforge-webproxy.service, and runs
systemctl --user daemon-reload.
It does not enable or start the service unless passed --start:
./install.sh --start
systemctl --user status atlasforge-webproxy.service.venv/bin/python -m pip install -e ".[test]"
.venv/bin/python -m pytestUse an unused non-8765 port for live smoke tests:
ATLASFORGE_WEB_PROXY_PORT=8799 .venv/bin/python -m atlasforge_webproxy.service --port 8799Search for images. Uses Brave API if configured, otherwise DuckDuckGo. Returns image URLs, source page URLs, thumbnails, dimensions. Optionally downloads top N images locally for vision tool access. The safesearch parameter controls content filtering: 'off' disables all filtering, 'moderate' is the default DDG behavior, 'on' is strict SFW.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of results | |
| query | Yes | Image search query | |
| safesearch | No | Content filter: 'off', 'moderate', or 'on' | off |
| fetch_top_n | No | Download top N images locally |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses backend behavior (Brave vs DuckDuckGo) and safesearch parameter effects. With no annotations, provides moderate transparency but lacks details on rate limits, permissions, or edge cases.
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?
Concise at 3-4 sentences, well-structured, front-loaded with main action. Slightly verbose on backend details but overall efficient.
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?
Covers return data, optional download, and safesearch. Lacks output schema, but description sufficiently explains returned fields. Completeness is good for a search tool.
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?
Adds meaning beyond schema: explains backends, safesearch options in context, and clarifies fetch_top_n downloads locally. Schema coverage is 100%, so baseline is 3; description provides extra value.
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 'Search for images' and details return types (URLs, thumbnails, dimensions) and optional local download. Distinct from sibling tools (PaperFetch, WebFetch, etc.) which are not image-specific.
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?
No explicit guidance on when to use this tool versus alternatives. Does not mention when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download an open-access paper PDF directly and extract full paper text when possible. Use this for arXiv/PDF paper sources before quoting a paper. Returns local artifact paths, SHA-256, page extraction metadata, and extracted text. This is separate from webpage WebFetch.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Paper landing URL or direct PDF URL | |
| max_chars | No | Max extracted text chars to return; -1 for all extracted text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It notes extraction is conditional ('when possible') and lists return values, but does not mention authentication needs, rate limits, or potential failure modes for non-open-access papers.
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 sentences cover all essential information with no wasted words. The first sentence front-loads the action and resource, while the second lists outputs concisely.
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 simple tool with 2 parameters and no output schema, the description covers purpose, usage, and returns. It lacks error handling details but is otherwise sufficient.
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%, so the schema already documents parameters. The description adds minor clarification (URL can be landing page or PDF) but does not significantly augment schema information.
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 downloads open-access paper PDFs and extracts text. It specifies the resource (arXiv/PDF paper sources) and distinguishes from WebFetch, making its purpose unmistakable.
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 explicitly states to use this for arXiv/PDF paper sources before quoting a paper, providing clear context. However, it does not include when not to use it or alternative tools, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch content from a URL. Returns raw extracted content: title, headings, full text, and links. No summarization — returns the actual page content. Reddit URLs auto-route to JSON API. Image URLs auto-detect and save locally. Cached for 24h per URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch content from | |
| prompt | Yes | Ignored — raw content is returned instead of a summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behaviors: returns raw extracted content, no summarization, automatic handling for Reddit URLs and images, and caching for 24 hours. It does not cover error handling or rate limits, but covers the most critical aspects.
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 at four sentences, front-loaded with the main purpose, and every sentence adds value without 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 the tool's simplicity (2 parameters, no output schema), the description covers the essential aspects: what is returned, special cases, and caching behavior. It lacks details on error handling and output format structure, but is largely complete for a fetch tool.
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?
The input schema has 100% coverage with clear descriptions for both parameters. The description adds extra context about the 'prompt' parameter being ignored and special URL handling, but no additional detail beyond what the schema already provides.
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 verb ('fetch') and resource ('content from a URL'), lists specific return fields (title, headings, text, links), and distinguishes it from sibling tools like ImageSearch and WebSearch which 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (when you need raw content from a URL) and what it does not do (no summarization). It also covers special cases like Reddit and images. However, it does not explicitly mention when not to use it or provide direct comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combined search + fetch: searches the web, then fetches the top N result pages. Returns search results plus extracted content from each page. Single call for research queries.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of search results | |
| query | Yes | Search query | |
| max_chars | No | Max text chars per page | |
| fetch_top_n | No | How many top results to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the combined functionality and return type but does not cover failure modes, rate limits, or how parameters interact (e.g., if fetch_top_n exceeds count). Without annotations, more behavioral detail would be beneficial.
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 with no redundant information. The first sentence captures the core functionality, the second clarifies the output. Ideal length.
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 the high-level behavior but does not specify the output format or how parameters interact. For a research tool combining two operations, users might want to know if the extracted content is plain text, if there are limits on total characters, etc. The description is sufficient for basic understanding but not fully comprehensive.
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 schema describes each parameter individually, the tool description explains the interaction: it searches and then fetches the top N (fetch_top_n) of the search results. This clarifies the workflow and the relationship between count and fetch_top_n.
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 performs a combined search and fetch operation, returning both search results and extracted content. This differentiates it from sibling tools like WebSearch (search only) and WebFetch (fetch only), as well as ImageSearch and PaperFetch.
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 recommends using this tool for research queries, implying it's best when both search and content extraction are needed. It doesn't explicitly exclude other use cases or mention alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web for information. Returns unfiltered search results with title, URL, and snippet for each result. No domain blocks, no content filtering. Uses Brave API if configured, otherwise DuckDuckGo.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to use | |
| allowed_domains | No | Only include search results from these domains | |
| blocked_domains | No | Never include search results from these domains |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the unfiltered nature of results and the backend API (Brave or DuckDuckGo), which adds value beyond the schema. However, it lacks details on rate limits, result count, error handling, or any potential restrictions (e.g., content blocking by default).
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 two sentences, front-loads the core purpose, and includes relevant behavioral details without redundancy. Every sentence serves a clear purpose.
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 lack of output schema, the description adequately explains what is returned (title, URL, snippet). However, it omits details on pagination, result count, and error behavior, which could be important for an agent using this tool.
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 the description adds minimal extra meaning. It mentions 'no domain blocks' which aligns with the allowed/blocked domains parameters, but it does not elaborate on parameter usage or format beyond what the schema provides.
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's function (search the web for information) and specifies what it returns (title, URL, snippet). It also distinguishes from sibling tools like ImageSearch and PaperFetch by focusing on general web search.
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 implies when to use (for general web search) but does not provide explicit guidance on when not to use or how it compares to siblings like WebResearch or WebFetch. No exclusions or alternatives are mentioned.
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.1.0ImageSearchPaperFetchWebFetchWebResearchWebSearchEach tool has a distinct purpose: image search, paper download, generic URL fetch, web search, and combined search+fetch. Clear boundaries prevent confusion.
All names follow a consistent pattern: noun (Image, Paper, Web) + action verb (Search, Fetch, Research). No mixing of styles.
5 tools is well-scoped for a web proxy. Each tool covers a specific need without redundancy or overwhelming number.
Core operations (search, fetch, image search, paper download, combined research) are present. Minor gap: no dedicated video search or social media extraction, but reasonable for general web access.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The best web search for your AI Agent
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
Reliable web fetching for AI agents with retry, circuit breaker, caching, and anti-bot bypass
Agent-native search engine with live web research optimized for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DragonShadows1978/AtlasForge-WebProxy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
