proxy-scraper
You can get working free proxies, verify them from your own machine, and fetch public web pages through them.
Get proxies instantly from an hourly-updated public list, with filters for protocol, country, HTTPS, elite anonymity, stability, latency, speed, uptime, datacenter exclusion, blocklist exclusion, and sites like Google/Reddit/Amazon.
Check proxies locally in
livemode (recheck the hourly list) orfullmode (scan all sources), returning proxies verified from your network right now.Fetch a public URL through a proxy, automatically retrying other proxies on failure, with optional country/protocol selection, raw HTML output, and text truncation.
Use proxy details such as ready-to-use URLs, latency, country, provider, anonymity, HTTPS support, uptime, speed, and per-check outcomes.
Respect safety limits:
fetch_urlrefuses local/private addresses, follows redirects, and is intended for GET requests, not logins or personal data.
Click on "Deploy 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., "@proxy-scraperget me a fresh list of working proxies"
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.
English · 简体中文 · Español · Deutsch · Русский · Português (Brasil) · Français
Install · Live list · Check states · For AI agents · Proxy server · Recipes · Options · FAQ · All docs
Proxy checks you can inspect: what passed, what failed, and when. proxy-scraper collects public HTTP, SOCKS4 and SOCKS5 proxies from hundreds of lists, runs up to four checks on each one and keeps the outcome of each check for the proxies it lists (for the rest it counts how each check ended), so "working" is something you can look at instead of a label you have to trust.
https://github.com/user-attachments/assets/b99c1d8f-5bce-4a52-a8a9-b9c2c726301b
21 seconds · real interface, example numbers, documentation IPs · mp4
Try it – no install needed, uvx comes with uv (pipx run does the same):
uvx proxy-scraper-cli --pick 3 --verify # up to 3 proxies from the hourly list that pass right now, from your network
uvx proxy-scraper-cli --diagnose socks5://HOST:PORT # one proxy, check by check: what it did and what it didn'tA real terminal recording, made against six simulated proxies on localhost (reproduce it). It shows how results are reported. It measures nothing about public proxies.
The package is proxy-scraper-cli on PyPI (the plain name is taken). Once installed, the command is proxy-scraper. --verify and --diagnose need version 1.30 or newer.
Three ways to get proxies, and what "checked" means for each:
Command | Where the proxies come from | Checked | Takes |
| the published list | from GitHub's servers when the list was built, about every hour | under a second |
| the published list | now, from your network | seconds to a minute and a half at most |
| every list the tool knows | now, from your network | minutes (about three in the hourly runs) |
What you get
Every check has an outcome you can read.
passed,failed,unavailableorskipped, with a reason code, the target and the time, in the terminal, in JSON and from Python. A check that didn't run is never shown as passed, and a check target that is down doesn't turn the proxies checked against it into failures. → Check statesFresh when it matters.
--pick --verifychecks a few proxies from your own network, usually in seconds.--recheckdoes the same for a list of your own, and--diagnosetells you why one proxy doesn't work.More than a list. A rotating local proxy server, a Python API, an MCP server for AI agents, Docker, and exports for curl, proxychains, Clash and sing-box.
What it can't do. Free proxies are run by strangers, and of one hour's list only about a quarter is on the list again a day later. A pass is one measurement, from one network, against test targets: it is not a promise for the next hour or for the site you care about. The HTTPS check is a verified TLS connection to one test host, not a security rating. Use free proxies for public data and testing, never for logins, payments or anything personal. → What the numbers show and what they don't · Why free proxies fail · How it compares · Who runs free proxies
Only want the lists? You don't need this tool: free-proxy-list has them as plain files per protocol and country, rebuilt about every hour. Or straight from here: all.txt · http.txt · socks4.txt · socks5.txt · proxies.json · more formats
Used by: the hourly list is a built-in source of monosans/proxy-scraper-checker and gfpcom/free-proxy-list.
Install
With pipx (recommended – gives you a proxy-scraper command in its own environment):
pipx install proxy-scraper-cli
proxy-scraperWith Homebrew on macOS and Linux:
brew install maximilianfeix/tap/proxy-scraperThe formula follows each release within about a day.
Docker, pip, a faster event loop, the latest main, tab completion and where state and results are stored: every other way to install.
Started without arguments, a wizard asks what you are looking for – a preset (find everything, browsing, maximum anonymity, fast, a few right now, recheck, proxy server right away, …) or step by step: the wizard and its presets.
Keys: ↑↓ select · Space toggle · 1–9 jump · Enter next · Esc back · q quit. In scripts and cron jobs the wizard never shows up – pass options or -y.
Related MCP server: Oculr MCP
Live proxy list
Don't want to scan yourself? About every hour GitHub Actions runs the tool and publishes the hits to the proxy-list branch – every entry passed the first request, the second request and the content check in the last run (the HTTPS test is recorded per entry, not required), best first: fast ones that are likely to still be up come on top.
Just want the lists? They also live in a repository of their own, maximilianfeix/free-proxy-list – one list per protocol, per country and per site, updated every hour, with the numbers of the last run on the front page. Watch or star it to keep it at hand. Other tools pull it too: monosans/proxy-scraper-checker and gfpcom/free-proxy-list use it as a built-in source.
→ Browse it on the website – search, filter by type, country, HTTPS, provider and latency, see how long each proxy has been on the list and in how many of the week's runs, copy or download exactly the proxies you need.
Every protocol and country also has its own page with a plain download, e.g. SOCKS5 or Germany (country/de/proxies.txt).
List | Format | Link |
All |
| |
HTTP · SOCKS4 · SOCKS5 |
| |
HTTPS-capable only |
| |
Elite only |
| |
Gets through to Google · Reddit · Amazon · Instagram · TikTok · Discord (one test request got a normal page in the last run) |
| google.txt · reddit.txt · amazon.txt · instagram.txt · tiktok.txt · discord.txt |
Stable, on the list in 90 %+ of this week's runs |
| |
With all details | latency, country, HTTPS, anonymity, exit IP, uptime, sites |
curl -s https://raw.githubusercontent.com/maximilianfeix/proxy-scraper/proxy-list/socks5.txt | headWhere they come from: which free proxy lists actually work ranks every source of the hourly runs – how many proxies each one lists, how many passed every check and the share. The same as data: sources.json.
Over time: every day the first run's proxies.json is kept for good as a gzipped asset of the release of that year, like snapshots-2026 – proxies-2026-09-28.json.gz and so on, for anyone who wants to look at free proxies over weeks and months.
Every file is also on GitHub Pages, which sits behind a CDN, isn't rate limited like raw.githubusercontent and sends CORS headers, so it works straight from the browser: https://proxy-scraper.de/socks5.txt. jsDelivr works too, but can lag behind by a few hours.
Or let the tool start from it: proxy-scraper --recheck live downloads the list and checks it again from your network – well under a minute instead of a full scan. How many still work from your network differs a lot from the list's own count, which is the point of checking again. Add --serve and the result is a rotating proxy.
Check states
Every check of a proxy ends in one of four states. They are in proxies.json, in the CSV, in --pick --json, in --diagnose, in the Python API (result.checks) and in the MCP results.
State | Meaning |
| The check ran and the proxy did what was asked. |
| The check ran, its target was fine, and the proxy did not do what was asked. |
| The check could not run, or says nothing about the proxy: its target didn't answer directly either, there was no reference to compare with, or this machine ran out of sockets. |
| Left out on purpose: |
Two rules follow from that:
A check that didn't run is never
passed. Before 1.30, a run without a reachable second target kept every proxy as if it had been confirmed, and a missing reference page looked like "content unchanged".A check target that is down doesn't fail the proxies checked against it. When a second request, a content request that returned a different page, or an HTTPS test fails, the tool asks the target directly: at most once every 3 seconds however many proxies fail in between, and a "down" answer is reused for 10 seconds. If the target doesn't answer, the proxy's check is
unavailable, notfailed. For the first request a scan does it differently: it watches the target, switches to another one and checks the affected proxies again.--diagnoseand--pick --verifyhave no such watcher and ask directly, as for the later checks. Two things are never asked about, because the target did answer: a second site that saw a different exit IP, and a proxy that could not be connected to in the first place.
The checks, what each passed does and doesn't mean, the fields and every reason code: docs/check-states.md.
For AI agents (MCP)
proxy-scraper-mcp is an MCP server: Claude Code, Claude Desktop, Cursor, VS Code, Codex and any other MCP client can ask for working proxies and load pages through them.
Tool | What it does |
| proxies from the hourly list, as checked in its last run – filter by protocol, country, HTTPS, elite, no datacenter, not blocklisted, stable, uptime, latency, gets through to Google/Reddit/Amazon |
| checks proxies from your own network, so they work from where your code runs (30–90 s, reports progress) |
| loads a page through a proxy from the checked list, switches proxies by itself when one fails, returns readable text – HTTPS only through proxies that passed the TLS test |
Things to ask your agent: "Load bbc.com/news as seen from the UK", "Give me 5 SOCKS5 proxies from Germany that aren't in a datacenter", "Check which of these sites block free proxies".
Needs uv – it fetches a suitable Python by itself if yours is older than 3.10. Claude Code:
claude mcp add proxy-scraper -- uvx --python ">=3.10" --from "proxy-scraper-cli[mcp]" proxy-scraper-mcpClaude Desktop, Cursor and most other clients – add this to the MCP config (Claude Desktop: Settings → Developer → Edit Config, Cursor: ~/.cursor/mcp.json):
{
"mcpServers": {
"proxy-scraper": {
"command": "uvx",
"args": ["--python", ">=3.10", "--from", "proxy-scraper-cli[mcp]", "proxy-scraper-mcp"]
}
}
}VS Code, Codex, Docker, or without uv: setup for every other client. It's also in the official MCP registry as io.github.maximilianfeix/proxy-scraper, so clients that browse the registry can install it from there.
The server tells agents what it tells you: free proxies are run by strangers, so no logins, cookies or personal data through them. Local and private addresses are refused, and results go to proxy-scraper's data folder, not into the project you're working in.
Examples
# 50 proxies that can do HTTPS – then stop
proxy-scraper --want 50 --https-only
# only Germany, Austria and Switzerland, the 20,000 most promising candidates
proxy-scraper --country DE,AT,CH -l 20000
# fast elite SOCKS5 proxies
proxy-scraper --types socks5 --anonymity elite --max-latency 1500
# 20 proxies that really reach Google AND Discord
proxy-scraper --target google.com --target discord.com --want 20
# only recheck the last hits (plus history) – takes seconds
proxy-scraper --recheck
# wizard with defaults – it keeps what you already passed
proxy-scraper -i --country DE
# which sources deliver the most?
proxy-scraper --list-sourcesRunning from a clone? Replace proxy-scraper with python3 proxy_scraper.py.
From Python
from proxyscraper import check_proxies, find_proxies
if __name__ == "__main__": # needed on macOS/Windows, the parser uses a process pool
for p in find_proxies(want=20, https=True, countries=["DE", "NL"], no_datacenter=True):
print(p.url, p.latency, p.country, p.org)
alive = check_proxies(["socks5://1.2.3.4:1080", "5.6.7.8:3128"]) # your own listSame run as the command line – sources, learning, every check, result files – just without terminal output. Each result has url, latency, exit_ip, https, anonymity, country, asn, org and hosting. There's an async version of both (find_proxies_async, check_proxies_async).
Don't need a fresh scan? live_proxies takes the live list instead – no checks, one download, done in about a second:
import itertools, requests
from proxyscraper import live_proxies
proxies = live_proxies(types=["socks5"], https=True, min_uptime=90) # the reliable ones this week
pool = itertools.cycle(p.url for p in proxies)
r = requests.get("https://api.ipify.org", proxies={"https": next(pool)}, timeout=15) # pip install "requests[socks]"Same filters as find_proxies, plus min_uptime, works_on (["google"], "reddit", "amazon", "instagram", "tiktok", "discord") and limit. Every result also has uptime_24h, uptime_7d, first_seen, up_for_hours and sites.
Or let the library do the retrying: ProxyRotator loads a URL through the list and moves on to the next proxy when one fails, and proxy_url() gives requests, httpx, Playwright or Scrapy one local address that rotates behind the scenes – Python API: rotating through the list.
Rotating proxy server
A list is nice – but usually you just want to enter one proxy address and have something behind it that keeps trying:
proxy-scraper --recheck --serve # recheck the last hits, then go – takes secondscurl -x http://127.0.0.1:8899 https://api.ipify.org # a different IP every time
curl -x socks5h://127.0.0.1:8899 https://api.ipify.org # SOCKS5 on the same port
curl -x http://country-de:x@127.0.0.1:8899 https://api.ipify.org # only German exits
curl -x http://session-cart42:x@127.0.0.1:8899 https://shop.example # same proxy for this session
curl http://127.0.0.1:8899/__proxy-scraper/status # pool and counters as JSON
curl http://127.0.0.1:8899/__proxy-scraper/metrics # the same for Prometheus/GrafanaLike commercial rotating proxies, the username carries what you want: country-XX, type-http|socks4|socks5 and session-NAME, combinable (country-us-type-socks5-session-a). It works for HTTP (Proxy-Authorization) and SOCKS5 (username/password auth). By default the password is ignored and the server only listens on 127.0.0.1.
To reach it from other machines, give it a password – every client then has to send it, over HTTP and SOCKS5 alike, and the status page wants it as Basic auth:
export PROXY_SCRAPER_SERVE_PASSWORD=$(openssl rand -hex 16) # the env var keeps it out of `ps`
proxy-scraper --recheck --serve --serve-host 0.0.0.0
curl -x "http://country-de:$PROXY_SCRAPER_SERVE_PASSWORD@your-server:8899" https://api.ipify.orgWithout a password the server refuses to start on any address but 127.0.0.1: that would be an open proxy for anyone who reaches the port (Docker publishes ports past host firewalls like ufw). If a firewall or -p 127.0.0.1:… already keeps others out, say so with --serve-open. The ready-made compose.yaml starts the server in Docker from the live list, with a password, a health check and learned state in a volume: put PROXY_PASSWORD=… into .env, then docker compose up -d.
Rotation strategies, sticky sessions, failover, background refill and the live dashboard: docs/proxy-server.md.
Proxy pool API
Some programs want a proxy address, not a proxy – to hand it to a browser, a worker or a queue. The same port answers plain HTTP requests with one:
curl http://127.0.0.1:8899/get # one proxy as JSON, chosen like a connection would be
curl "http://127.0.0.1:8899/get?country=DE&https=1&format=txt" # → http://203.0.113.7:8080
curl "http://127.0.0.1:8899/all?protocol=socks5&limit=20" # the 20 best SOCKS5 proxies
curl "http://127.0.0.1:8899/report?proxy=203.0.113.7:8080&ok=0" # it failed you – three times and it's outAll endpoints, filters and what's compatible with jhao104/proxy_pool: Proxy pool API.
Discord and Telegram bot
The live list can also come to you: bot/ is a Discord bot that posts every run into a server – a summary with the fastest proxies, the full lists per protocol as files, and slash commands like /proxies type:socks5 country:DE https:true. It sets up its own read-only channels when you invite it, and a GitHub Action deploys it to a server as a systemd service. The same process answers on Telegram too: /proxy de socks5 for one proxy with a curl line, /proxies 10 us https for a short list. Setup in bot/README.md.
Documentation
Everything that used to be further down this README now has its own page – all docs:
Features
What the tool does, check by check and feature by feature: How it works → Features.
Why not just download a list?
A list tells you what worked for its author when it was built. What the tool adds: How it works → Why not just download a list? · how it compares.
How it works
Sources, collecting, prioritizing, the checks, countries and providers, blocklists, learning: docs/how-it-works.md. Your own lists with --source: recipes.
Output
Every run gets its own folder; results/latest.txt always names the newest one – the layout is in docs/options.md.
Recipes
requests, httpx, aiohttp, Scrapy, Selenium, proxychains, Clash / Mihomo, sing-box, PAC, Proxifier, Burp Suite / ZAP / mitmproxy, pipes, a GitHub workflow, Windows: docs/recipes.md.
Options
Every option in one table: docs/options.md. Everything else: proxy-scraper --help
GitHub Actions
The workflows that test, lint, build the hourly list and release: docs/how-it-works.md. To use proxies in your own workflow: the GitHub Action.
FAQ
Who runs free proxies – and should you use them? · almost nothing gets through · Windows · fewer proxies than other lists · logins · how fresh the list is · is it safe: docs/faq.md.
Roadmap
What's next is in the open issues – ideas and wishes are welcome as an issue. During Hacktoberfest there are beginner-friendly issues with pointers on where to start. What shipped in each version: docs/roadmap.md.
Contributing
Bug reports, new sources and pull requests are very welcome – see CONTRIBUTING.md, and docs/ARCHITECTURE.md for how the pieces fit together. The short version:
pip install -e ".[dev]"
python3 -m pytest # runs offline – fake proxies on localhost
ruff check .
python3 docs/make_demo.py # regenerate the images in this READMEThe project structure, file by file, is in How it works.
Community
Questions, ideas and things you built with it go to Discussions – bugs to the issues. If proxy-scraper saves you time, a ⭐ helps others find it.
Thanks to everyone who helped build it – new sources, countries, Python 3.14, examples and more:
Want to join? Beginner-friendly issues say where to start.
From the same author: dejabuilt, an agent skill that checks GitHub before you build – it tells you whether a project idea already exists, with the numbers.
Acknowledgements
proxy-scraper stands on the work of the people who publish free proxy lists. Thanks to everyone listed in sources.json, and especially to
monosans/proxy-scraper-checker and gfpcom/free-proxy-list, whose curated source collections are read as meta sources
Textualize/rich, which draws the whole terminal UI
IP Geolocation by DB-IP – the free country database (CC BY 4.0) used for offline country lookups
httpbin, checkip.amazonaws.com, ifconfig.me, ipinfo.io, wtfismyip.com, ident.me and ip-api.com, used as check targets and for country lookups
Disclaimer
This tool only collects publicly listed proxies and checks whether they work. You are responsible for how you use them – respect the terms of the sites you visit and the laws where you live.
Made in Germany by @maximilianfeix · MIT License · Changelog · Security · Contributing
If proxy-scraper saves you time, a ⭐ helps others find it.
Available Tools
3 toolscheck_proxiesCheck proxies from this machineA
Find proxies that work from this machine's network right now.
Runs the same checks as the public list – handshake, second request, byte-for-byte content check, verified TLS – but from here, so the results were verified seconds ago from the network your code runs on. Slower than get_proxies: 30-90 s in live mode, and progress is reported while it runs. It also updates the local statistics proxy-scraper learns from.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | live: check the hourly list again from here (30-90 s). full: collect from all 700+ sources (a few minutes) | live |
| want | No | Stop once this many work | |
| protocol | No | Proxy protocol to look for | any |
| countries | No | Two-letter country codes of the exit IP, e.g. ['DE', 'NL']. Empty = any country. | |
| elite_only | No | Only proxies the target can't recognize as proxies | |
| https_only | No | Only proxies that tunnel HTTPS with verified TLS | |
| max_latency_ms | No | Maximum response time, 0 = any | |
| exclude_datacenter | No | Skip exits in datacenters | |
| exclude_blocklisted | No | Skip exits on the SpamCop blocklist |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | Yes | live = the hourly list checked again, full = all 700+ sources |
| note | Yes | What to do if none were found |
| proxies | Yes | Working from this machine right now, fastest first |
| took_seconds | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: the concrete runtime (30-90 s live, minutes for full), that progress is reported during execution, the exact verification steps performed (handshake, second request, byte-for-byte content, verified TLS), and the side effect of updating local proxy-scraper statistics. That last point explains why readOnlyHint=false despite it being a lookup-style 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?
Three tight sentences, front-loaded with the core promise, then the verification detail, then the cost comparison and side effect. Every sentence earns its place with no redundant restatement of the name or schema.
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?
An output schema exists so return values need no explanation, and the description covers the parts structured data can't: runtime, progress behavior, verification rigor, relative cost against the sibling, and the local-statistics side effect that reconciles with the annotations.
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 all nine parameters are documented in the schema, and the description adds only incidental detail (the 30-90 s figure for live mode). Baseline 3 is appropriate when the schema fully carries parameter meaning.
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?
States a specific verb (find/verify) and resource (proxies) with a clear distinguishing scope: proxies that work from THIS machine's network right now. It also explicitly positions itself against the get_proxies sibling, so an agent can differentiate without opening either schema.
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?
Gives clear context for when this tool is worth the cost versus get_proxies ('Slower than get_proxies: 30-90 s'), and explains the live-vs-full tradeoff pattern. It stops short of an explicit 'use get_proxies when you don't need current-network verification' exclusion, so it's strong but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_urlFetch a page through a proxyARead-only
Load a web page through a verified free proxy and return it as readable text.
If a proxy fails, the next one is tried by itself (up to 8), redirects are followed. HTTPS only goes through proxies that passed a verified-TLS test, so the page can't be changed on the way. Local and private addresses are refused, also when a redirect points there. Useful to see a site from another country or when a site blocks this machine. GET only; don't use it for logins or anything with personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full http:// or https:// URL of a public site | |
| country | No | Two-letter code: load the page as seen from this country. Empty = any country. | |
| protocol | No | Only use proxies of this protocol | any |
| raw_html | No | Return the HTML as it is instead of readable text | |
| max_chars | No | Cut the text after this many characters |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| via | Yes | The proxy that delivered the page |
| note | Yes | |
| text | Yes | Readable text (HTML is turned into plain text unless raw_html is set) |
| bytes | Yes | Size of the response body |
| status | Yes | HTTP status of the target, e.g. 200, 403, 404 |
| final_url | Yes | After redirects |
| truncated | Yes | True if the text was cut at max_chars |
| elapsed_ms | Yes | |
| content_type | Yes | |
| proxy_country | Yes | Country the target saw the request from |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: up to 8 proxies tried in sequence, redirects followed, TLS-verified proxies only for HTTPS, and refusal of local/private addresses even via redirect. These are exactly the operational traits (failure handling, safety boundaries, mutation risk) an agent needs and that readOnlyHint/openWorldHint do not convey.
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?
Front-loaded with purpose, then constraints, then usage caveats — every sentence carries information. Slightly dense in the middle sentence about proxy/TLS/redirect handling, but nothing is wasted.
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?
An output schema exists, so return-value detail is not required. The description covers mechanism, safety boundaries, failure behavior, and use/exclusion cases, which is complete for a 5-parameter read tool with one required argument.
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 each parameter is already documented in the schema. The description only loosely maps to parameters ('readable text' implies raw_html, 'from another country' implies country). Baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb and resource plus the mechanism: 'Load a web page through a verified free proxy and return it as readable text.' This clearly distinguishes it from the proxy-management siblings (get_proxies, check_proxies), which do not return page content. An agent can tell what this tool produces without opening the schema.
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?
Gives explicit when-to-use ('see a site from another country or when a site blocks this machine') and when-not ('GET only; don't use it for logins or anything with personal data'). It stops short of naming an alternative tool for those excluded cases, so it falls just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_proxiesGet working proxiesARead-onlyIdempotent
Get working free proxies right now, fastest first.
Instant: comes from a public list that is re-checked every hour from GitHub's servers, so a proxy may have died since, and some behave differently from this machine's network. Use check_proxies when they must work from here right now. Every result has a ready-to-use url like socks5://1.2.3.4:1080.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (fastest first) | |
| protocol | No | Proxy protocol. socks5 works for any TCP traffic, http is what most HTTP clients expect. | any |
| works_on | No | Only proxies that got through to all of these sites in the last hourly check (most free proxies get a captcha or a 403 there) | |
| countries | No | Two-letter country codes of the exit IP, e.g. ['DE', 'NL']. Empty = any country. | |
| elite_only | No | Only proxies the target can't recognize as proxies | |
| https_only | No | Only proxies that tunnel HTTPS with verified TLS. Needed for https:// sites. | |
| stable_only | No | Only proxies that have worked for 24 h or more | |
| max_latency_ms | No | Maximum response time, 0 = any | |
| min_speed_kbps | No | Only proxies that downloaded at least this many KiB/s in the last hourly check, e.g. 300 for loading real pages | |
| exclude_datacenter | No | Skip exits in datacenters (blocked by many sites) | |
| min_uptime_percent | No | Only proxies that passed at least this share of the last 7 days' hourly checks, e.g. 90 for the most reliable | |
| exclude_blocklisted | No | Skip exits on the SpamCop blocklist (fewer captchas) |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | What to do if fewer proxies matched than asked for |
| matched | Yes | How many proxies in the list pass the filters (limit cuts the rest) |
| proxies | Yes | Fastest first |
| list_stale | No | True if the list is older than it should be (the hourly run missed, or reloading it failed): its proxies were checked at list_updated – use check_proxies for fresh ones |
| list_updated | Yes | When the list was last checked (ISO 8601, UTC) |
| list_age_minutes | Yes | Minutes since that check |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/idempotent/openWorld; the description goes well beyond by disclosing data provenance (public list re-checked hourly from GitHub), the staleness risk ('a proxy may have died since'), network-dependence caveat, and the exact result shape (a ready-to-use url like socks5://1.2.3.4:1080). This is behaviorally rich relative to what the annotations give.
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?
Front-loaded with the capability and ordering guarantee, then the crucial caveat, then the routing alternative, then the output format. Every sentence earns its place with no filler.
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?
Output schema exists, so return details need not be restated; safety is covered by annotations; and the description supplies the two things structured fields cannot—data freshness caveats and the sibling routing rule. Nothing an agent needs to call this correctly is missing.
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% and each of the 12 parameters already carries its own explanation, so the schema does the heavy lifting. The description adds only ambient context ('fastest first') without new per-parameter meaning, which matches the baseline 3.
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?
States a concrete verb+resource (get working free proxies) with scope qualifier (fastest first) and an explicit contrast against the sibling check_proxies. An agent can distinguish it from check_proxies without opening either schema.
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?
Names the alternative explicitly and gives the selecting condition: 'Use check_proxies when they must work from here right now.' It also implicitly frames when this tool is fine (instant, best-effort lists), leaving nothing to inference.
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.
2 tool updates
v1.30.0- Changed
check_proxies2 fields changed- added
Output schema / $defs / Proxy / properties / checked_atAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "When this proxy itself was last checked (ISO 8601, UTC) – for the live list: by the hourly run, not now", + "title": "Checked At" +} - added
Output schema / $defs / Proxy / properties / checksAdded value: +{ + "additionalProperties": { + "additionalProperties": true, + "type": "object" + }, + "description": "How each check ended: basic, confirm, content, https -> state (passed, failed, unavailable = could not run, skipped = left out) with a reason code, the target and the time. Empty for lists from before these were recorded", + "title": "Checks", + "type": "object" +}
- Changed
get_proxies3 fields changed- added
Output schema / $defs / Proxy / properties / checked_atAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "When this proxy itself was last checked (ISO 8601, UTC) – for the live list: by the hourly run, not now", + "title": "Checked At" +} - added
Output schema / $defs / Proxy / properties / checksAdded value: +{ + "additionalProperties": { + "additionalProperties": true, + "type": "object" + }, + "description": "How each check ended: basic, confirm, content, https -> state (passed, failed, unavailable = could not run, skipped = left out) with a reason code, the target and the time. Empty for lists from before these were recorded", + "title": "Checks", + "type": "object" +} - added
Output schema / properties / list_staleAdded value: +{ + "default": false, + "description": "True if the list is older than it should be (the hourly run missed, or reloading it failed): its proxies were checked at list_updated – use check_proxies for fresh ones", + "title": "List Stale", + "type": "boolean" +}
3 tool updates
v1.25.0- First observed
check_proxies - First observed
fetch_url - First observed
get_proxies
TDQS
Scored across 3 tools
get_proxies and check_proxies both return proxy lists and could be confused at a glance, but the descriptions clearly delineate cached-public-list vs. locally-verified, and fetch_url is a distinct consumer action. Boundaries are recoverable without much risk of misselection.
All three tools use a clean snake_case verb_noun pattern (get_proxies, check_proxies, fetch_url) with consistent imperative verbs. No mixed conventions or vague naming.
Three tools is slightly lean but each earns its place: acquire a list, verify locally, then use a proxy to fetch. The small surface fits a narrow proxy-scraping domain rather than feeling arbitrarily truncated.
The core workflow (list, validate, use) is fully covered, but the toolset mentions updating local statistics that no tool can read back, and there is no filtering by protocol/country or proxy-detail retrieval. These are minor gaps an agent can work around.
Maintenance
Related MCP Connectors
Free proxy list, live proxy checker and IP lookup for AI agents. No key, nothing to install.
Control dedicated 4G mobile and residential proxies on mobileproxy.space from AI agents.
Proxy-rotated web scraping and cross-platform intelligence for AI agents.
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
Related MCP Servers
AlicenseAqualityFmaintenanceA Model Context Protocol server that enables AI agents to fetch live web content with JavaScript rendering, proxy rotation, and anti-bot evasion.963 npm60MIT- AlicenseNot gradedqualityDmaintenanceEnables AI agents to create and control real, isolated browser profiles with engine-level fingerprinting and per-profile proxies, providing antidetect browsing capabilities through a Model Context Protocol interface.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to access file systems, fetch web content, query databases, and execute shell commands through the standardized Model Context Protocol.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to autonomously operate web browsers through the Model Context Protocol, including navigating pages, clicking, typing, filling forms, and extracting structured data.MIT