proxy-scraper

Get working proxies

get_proxies

Read-onlyIdempotent

Fetch verified free proxies sorted by speed, filtered by protocol, country, latency, uptime, and target sites, returning ready-to-use URLs for scraping, automation, or region-specific requests.

Instructions

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.30.0Oct 17, 2026

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"
+}

First observedv1.25.0Oct 6, 2026

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.

Deploy Server