HProxy MCP server: keyless access to free public proxy lists and checking

Who it's for

• Developers and automation script writers who work inside MCP clients and want their AI assistant to fetch a list of free public proxies, check whether a specific proxy answers right now, or look up IP information. The vendor ships ready-made setups for Claude Code, Claude Desktop, Cursor and Windsurf, so those clients get the lowest onboarding cost.
• Judging by the tool names, the three tools cover one familiar pipeline: proxy_list fetches the list, proxy_check verifies a single proxy, and ip_lookup looks up IP information. The exact parameters of each tool are not stated in the evidence — unconfirmed.
• The zero-configuration premise is explicit from the vendor: the server is built on the same keyless API, and the original text reads “No key, no signup, CORS open”. If you don't want to register an account or apply for a key just to run one experiment, you can use it directly — this is not something you need to re-verify.
• The premise of use (warning in the vendor's own words): every entry the list returns is a free public proxy, and fewer than half are expected to answer at any moment. Before using the results you must set a short timeout and move to the next one on failure. This is the officially stated way to use it, not an optional suggestion.
• Not a fit: business traffic that needs high availability and stable egress, or critical paths where you must promise something about privacy or logging — no such commitments exist in the evidence.
• Unknown: the filter parameters of the proxy list, its return fields, rate limits and quotas — none of these are stated in the evidence, unconfirmed.

First try in 3 minutes

Recommended main path: register the remote server with the single official Claude Code command, then make exactly one query.

1. Note the side effect before you start: every entry proxy_list returns is a free public proxy, and more than half will not answer at any given moment. Keep the timeout short and move to the next one on failure — the vendor states this as a usage requirement. A first try only needs to confirm that the chain works; do not route real traffic through the proxy at this step.
2. Run the official command in your terminal:

claude mcp add --transport http hproxy https://mcp.hproxy.com/mcp

1. No key and no signup step — the original text reads “No key, no signup”.
2. Call one low-risk capability: ask the assistant in conversation to call proxy_list and pull the current list. All three tools (proxy_list, proxy_check, ip_lookup) sit on the same keyless API; the evidence does not say whether they carry a read-only annotation, so starting with a query-style call is the safest first move.
3. Two success signals: the command completes, and once your client connects to the hproxy server the assistant can invoke the tool and return a proxy list. Which fields the list contains is not stated in the evidence, unconfirmed.

Side note: the official setups for Claude Desktop, Cursor and Windsurf are at hproxy.com/tools/ai; the evidence includes no per-client configuration snippets, so they are not individually confirmed.

Use cases

Case 1: batch-fetching proxies for a one-off connectivity experiment. Scenario: a script needs a batch of candidate public proxies and does not care whether any single one works. Approach: have the assistant call proxy_list to pull the current list. Expected result: you get a list of public proxies; per the official warning, fewer than half answer at any moment — in other words, fetch ten and usually fewer than five work right now. Set your experiment expectations to that ratio, and pair it with a short timeout and rotation retries. The list's fields and size cap are not stated in the evidence, unconfirmed.

Case 2: check a proxy before using it. Scenario: you have a proxy address from the list or another source and want to confirm it answers right now before putting it to real use. Approach: have the assistant call proxy_check on that proxy. What is confirmed: the vendor provides this checking tool, and it is built on the keyless API. Its parameter shape and return format are not stated in the evidence, unconfirmed — follow the parameter descriptions bundled with the tool in your client and do not use guessed parameters.

Boundaries of use

• Read/write nature: by their names, the three tools belong to the query-proxy-and-IP-information category, but the vendor declares no read-only annotation or read/write classification, so no independent safety conclusion is drawn here.
• Credentials: no key, no signup — the original text reads “No key, no signup, CORS open”; there is no evidence of an account system.
• Local data: the evidence does not mention the tools reading or writing local files or local state, unconfirmed; that alone implies no further guarantee.
• Side effects and checkpoints: the main risk sits on the results side — free public proxies are more than half unusable and need a short timeout with rotation. Confirm with a human before routing real traffic through them; the vendor does not say who maintains these proxies or what their logging policy is, so traffic involving account credentials or private data should not depend on free public proxies.
• Explicit vendor limits: more than half the proxies are unresponsive at any moment; a short timeout and moving to the next one on failure are premises the vendor states outright.
• Disconnect and cleanup: the evidence includes no method for removing or disconnecting the server, unconfirmed.
• Key unconfirmed information: rate limits and quotas, tool parameter details, return field structure, service availability commitments — none are stated in the evidence.