Skip to main content
Glama

tests Release Live proxies PyPI Downloads Python Stars License

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't

A 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

proxy-scraper --pick 5

the published list

from GitHub's servers when the list was built, about every hour

under a second

proxy-scraper --pick 5 --verify

the published list

now, from your network

seconds to a minute and a half at most

proxy-scraper -y

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, unavailable or skipped, 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 states

  • Fresh when it matters. --pick --verify checks a few proxies from your own network, usually in seconds. --recheck does the same for a list of your own, and --diagnose tells 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-scraper

With Homebrew on macOS and Linux:

brew install maximilianfeix/tap/proxy-scraper

The 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).

Proxies HTTP SOCKS4 SOCKS5 Updated

List

Format

Link

All

socks5://1.2.3.4:1080

all.txt

HTTP · SOCKS4 · SOCKS5

1.2.3.4:8080

http.txt · socks4.txt · socks5.txt

HTTPS-capable only

type://ip:port

https.txt

Elite only

type://ip:port

elite.txt

Gets through to Google · Reddit · Amazon · Instagram · TikTok · Discord (one test request got a normal page in the last run)

type://ip:port

google.txt · reddit.txt · amazon.txt · instagram.txt · tiktok.txt · discord.txt

Stable, on the list in 90 %+ of this week's runs

type://ip:port

stable.txt

With all details

latency, country, HTTPS, anonymity, exit IP, uptime, sites

proxies.json · proxies.csv

curl -s https://raw.githubusercontent.com/maximilianfeix/proxy-scraper/proxy-list/socks5.txt | head

Where 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

passed

The check ran and the proxy did what was asked.

failed

The check ran, its target was fine, and the proxy did not do what was asked.

unavailable

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.

skipped

Left out on purpose: --fast, a filter had already ruled the proxy out, or an earlier check failed.

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, not failed. For the first request a scan does it differently: it watches the target, switches to another one and checks the affected proxies again. --diagnose and --pick --verify have 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.

proxy-scraper MCP server on Glama

Tool

What it does

get_proxies

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

check_proxies

checks proxies from your own network, so they work from where your code runs (30–90 s, reports progress)

fetch_url

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-mcp

Claude 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-sources

Running 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 list

Same 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 seconds
curl -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/Grafana

Like 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.org

Without 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 out

All 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 README

The 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

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 tools
check_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.

NameRequiredDescriptionDefault
modeNolive: check the hourly list again from here (30-90 s). full: collect from all 700+ sources (a few minutes)live
wantNoStop once this many work
protocolNoProxy protocol to look forany
countriesNoTwo-letter country codes of the exit IP, e.g. ['DE', 'NL']. Empty = any country.
elite_onlyNoOnly proxies the target can't recognize as proxies
https_onlyNoOnly proxies that tunnel HTTPS with verified TLS
max_latency_msNoMaximum response time, 0 = any
exclude_datacenterNoSkip exits in datacenters
exclude_blocklistedNoSkip exits on the SpamCop blocklist

Output Schema

NameRequiredDescription
modeYeslive = the hourly list checked again, full = all 700+ sources
noteYesWhat to do if none were found
proxiesYesWorking from this machine right now, fastest first
took_secondsYes

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 proxyA
Read-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.

NameRequiredDescriptionDefault
urlYesFull http:// or https:// URL of a public site
countryNoTwo-letter code: load the page as seen from this country. Empty = any country.
protocolNoOnly use proxies of this protocolany
raw_htmlNoReturn the HTML as it is instead of readable text
max_charsNoCut the text after this many characters

Output Schema

NameRequiredDescription
urlYes
viaYesThe proxy that delivered the page
noteYes
textYesReadable text (HTML is turned into plain text unless raw_html is set)
bytesYesSize of the response body
statusYesHTTP status of the target, e.g. 200, 403, 404
final_urlYesAfter redirects
truncatedYesTrue if the text was cut at max_chars
elapsed_msYes
content_typeYes
proxy_countryYesCountry the target saw the request from

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 proxiesA
Read-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.

NameRequiredDescriptionDefault
limitNoHow many to return (fastest first)
protocolNoProxy protocol. socks5 works for any TCP traffic, http is what most HTTP clients expect.any
works_onNoOnly proxies that got through to all of these sites in the last hourly check (most free proxies get a captcha or a 403 there)
countriesNoTwo-letter country codes of the exit IP, e.g. ['DE', 'NL']. Empty = any country.
elite_onlyNoOnly proxies the target can't recognize as proxies
https_onlyNoOnly proxies that tunnel HTTPS with verified TLS. Needed for https:// sites.
stable_onlyNoOnly proxies that have worked for 24 h or more
max_latency_msNoMaximum response time, 0 = any
min_speed_kbpsNoOnly proxies that downloaded at least this many KiB/s in the last hourly check, e.g. 300 for loading real pages
exclude_datacenterNoSkip exits in datacenters (blocked by many sites)
min_uptime_percentNoOnly proxies that passed at least this share of the last 7 days' hourly checks, e.g. 90 for the most reliable
exclude_blocklistedNoSkip exits on the SpamCop blocklist (fewer captchas)

Output Schema

NameRequiredDescription
noteYesWhat to do if fewer proxies matched than asked for
matchedYesHow many proxies in the list pass the filters (limit cuts the rest)
proxiesYesFastest first
list_staleNoTrue 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_updatedYesWhen the list was last checked (ISO 8601, UTC)
list_age_minutesYesMinutes since that check

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

  1. 2 tool updatesv1.30.0
    • Changedcheck_proxies2 fields changed
      • addedOutput schema / $defs / Proxy / properties / checked_at
        Added 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"
        +}
      • addedOutput schema / $defs / Proxy / properties / checks
        Added 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"
        +}
    • Changedget_proxies3 fields changed
      • addedOutput schema / $defs / Proxy / properties / checked_at
        Added 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"
        +}
      • addedOutput schema / $defs / Proxy / properties / checks
        Added 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"
        +}
      • addedOutput schema / properties / list_stale
        Added 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"
        +}
  2. 3 tool updatesv1.25.0
    • First observedcheck_proxies
    • First observedfetch_url
    • First observedget_proxies

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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

ActivityActive
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    F
    maintenance
    A Model Context Protocol server that enables AI agents to fetch live web content with JavaScript rendering, proxy rotation, and anti-bot evasion.
    9
    63 npm
    60
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables 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