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., "@Litport Free Proxy MCP Server List the top 5 US HTTP proxies checked in the last 30 minutes"
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.
A local, stdio Model Context Protocol server that gives an MCP
client (Claude Desktop, Claude Code, or any other MCP-compatible agent) three bounded, read-only
tools over Litport's public free-proxy snapshot: list verified HTTP, SOCKS4, and SOCKS5 proxies,
pick the highest-ranked ones, and summarize the current snapshot. It never forwards traffic, never
accepts arbitrary URLs from tool callers, and exposes no write or side-effecting tools; it is a thin
wrapper around @litportnet/free-proxy-sdk.
Add this to your client's MCP server configuration (for Claude Desktop, claude_desktop_config.json;
for Claude Code, .mcp.json or claude mcp add):
{
"mcpServers": {
"free-proxy": {
"command": "npx",
"args": ["-y", "@litportnet/free-proxy-mcp"]
}
}
}No installation step is required beyond having Node.js 20+ available; npx fetches and runs the
package on demand. To install it explicitly instead:
npm install -g @litportnet/free-proxy-mcpRelated MCP server: mcpwrapped
All three tools are read-only and share the same underlying filters. country is a two-letter ISO
3166-1 alpha-2 code (case-insensitive). checkedWithinMin limits results to proxies checked within
the last 1-1440 minutes.
Tool | Description | Inputs |
| List verified free proxies matching filters. |
|
| Return the highest-ranked proxies matching filters. |
|
| Summarize the current proxy snapshot. |
|
list_proxies and pick_best_proxies return a count and a proxies array of normalized records
exactly as returned by the SDK. proxy_snapshot_stats returns the total matching count, counts by
protocol and anonymity, the top 10 countries by count, the share of matching proxies that support
HTTPS, latency min/median/p90/max across records that report latency, how many records have a known
seven-day uptime, and the newest and oldest lastChecked timestamps. Every response includes a
disclaimer field. Errors from the underlying SDK (invalid filters, request timeouts, malformed or
stale snapshots) are returned as { isError: true, content: [...] } rather than thrown, and never
include a stack trace.
Variable | Default | Purpose |
| the SDK's built-in snapshot URL | Absolute |
|
| Per-request timeout in milliseconds passed to the SDK client. |
npm install
npm testnpm test runs node --test over test/*.test.mjs: in-process unit tests that drive the server
through the MCP SDK's in-memory transport with an injected @litportnet/free-proxy-sdk client, and
an end-to-end test that spawns the server over stdio against a local HTTP fixture server, plus a
regression test that launches the server through a bin symlink the way npx does.
Free proxies are for testing only. Never route credentials, cookies, payment data, or private data through them.
List verified free proxies matching filters.
| Name | Required | Description | Default |
|---|---|---|---|
| https | No | Restrict results to proxies that do (true) or do not (false) support HTTPS. | |
| limit | No | Maximum number of proxies to return (1-50). | |
| country | No | Two-letter ISO 3166-1 alpha-2 country code (case-insensitive). | |
| protocol | No | Restrict results to this proxy protocol. | |
| anonymity | No | Restrict results to this anonymity classification. | |
| minChecks7d | No | Keep only proxies with at least this many checks in the last seven days. | |
| minUptime7d | No | Keep only proxies whose seven-day uptime percentage is at least this value. | |
| maxLatencyMs | No | Keep only proxies whose latest latency is at most this many milliseconds. | |
| checkedWithinMin | No | Only include proxies last checked within this many minutes (1-1440). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'List verified free proxies' which implies a read-only operation, but it does not disclose any behavioral details such as default filters, pagination, what 'verified' means, or how filters combine. It adds minimal value beyond the action itself.
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 a single, front-loaded sentence with zero waste. It states the action and resource clearly. It is appropriately concise for a list operation, though it could benefit from more context, it is efficiently structured.
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 tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It does not explain what 'verified' means, how filters interact, or what the response format looks like. An agent would need to rely entirely on the schema, which lacks behavioral and output context.
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% with detailed descriptions for all 9 parameters. The description's mention of 'matching filters' is generic and does not add specific meaning to any parameter. Baseline 3 is appropriate since the schema fully documents parameter semantics.
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 'List' and the resource 'verified free proxies', and mentions 'matching filters'. This is a specific action on a defined resource. However, it does not differentiate from sibling tools like pick_best_proxies or proxy_snapshot_stats, so it lacks sibling distinction.
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 provides no guidance on when to use this tool versus the siblings. It does not mention alternative tools, conditions, or exclusions. There is no context about when listing proxies is preferable to picking the best or getting snapshot stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the highest-ranked proxies matching filters.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of top-ranked proxies to return (1-25). | |
| https | No | Restrict results to proxies that do (true) or do not (false) support HTTPS. | |
| country | No | Two-letter ISO 3166-1 alpha-2 country code (case-insensitive). | |
| protocol | No | Restrict results to this proxy protocol. | |
| anonymity | No | Restrict results to this anonymity classification. | |
| minChecks7d | No | Keep only proxies with at least this many checks in the last seven days. | |
| minUptime7d | No | Keep only proxies whose seven-day uptime percentage is at least this value. | |
| maxLatencyMs | No | Keep only proxies whose latest latency is at most this many milliseconds. | |
| checkedWithinMin | No | Only include proxies last checked within this many minutes (1-1440). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It only states that proxies are returned; it doesn't explain what 'highest-ranked' means, how ranking is computed, whether the operation is read-only, what happens if no proxies match, or that default filters (like checkedWithinMin=30) apply. This is a significant gap for a tool with no annotation support.
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 a single, focused sentence with no filler, front-loading the core action. It is concise and efficiently structured, though its brevity sacrifices useful contextual details that are missing from other dimensions.
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 complexity (9 parameters, no output schema, no annotations), this description is far too thin. It doesn't explain return value structure, ranking methodology, default count behavior, or edge cases like empty results. An agent would need to infer essential behavior from parameter names alone, which is inadequate for reliable invocation.
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 provides 100% coverage with descriptions for all 9 parameters, so the baseline is 3. The description adds no parameter-specific meaning beyond the generic word 'filters,' which neither clarifies nor contradicts the schema's detailed descriptions.
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 states a specific verb ('Return') and resource ('highest-ranked proxies'), clearly indicating this tool selects a ranked subset rather than listing all proxies. It implicitly differentiates from the sibling list_proxies through the 'highest-ranked' qualifier, though it doesn't explicitly name alternatives.
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 guidance is given about when to use this tool versus list_proxies or proxy_snapshot_stats. The phrase 'matching filters' implies a filtering scenario, but it doesn't specify when ranking is preferable to a plain list, nor does it mention any exclusions or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize the current proxy snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Two-letter ISO 3166-1 alpha-2 country code (case-insensitive). | |
| protocol | No | Restrict results to this proxy protocol. | |
| checkedWithinMin | No | Only include proxies last checked within this many minutes (1-1440). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It clearly indicates 'Summarize' which is a read operation, but it does not disclose details like whether results are aggregated counts, whether it respects filters, or whether it returns any data at all. There is no contradiction, but the behavioral detail is thin.
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 a single, concise sentence that is front-loaded with the core purpose. It is efficient with no filler words, though it could be slightly more detailed without becoming verbose.
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 has 3 optional parameters and an output schema is absent, the description is adequate but minimal. It does not explain what kind of summary is produced (e.g., counts by country, protocol), which could be critical for an agent deciding whether to call this tool. The lack of output schema makes the description's lack of return-format detail a notable gap.
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 covers 100% of parameters, including descriptions for each (country, protocol, checkedWithinMin). The description does not add extra meaning beyond what the schema provides, so the baseline of 3 is appropriate. No additional parameter context is needed.
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 states a clear verb ('Summarize') and resource ('proxy snapshot'), but it is vague about what 'snapshot' means—it could refer to the current proxy pool state or a specific snapshot object. It does not differentiate from siblings like 'list_proxies' or 'pick_best_proxies' beyond the verb, so an agent might confuse it with a simple listing tool.
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 a read-only summarization but does not state when to use this tool versus 'list_proxies' or 'pick_best_proxies'. It lacks explicit guidance on use cases (e.g., for an overview of the current pool) or when to avoid it (e.g., when detailed per-proxy data is needed).
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.
v0.1.0list_proxiespick_best_proxiesproxy_snapshot_statsScored across 3 tools
Each tool has a clearly distinct purpose: stats summarizes the snapshot, list returns matching proxies, and pick_best returns the top-ranked ones. There is no meaningful overlap between them.
Most tools follow a verb_noun pattern (list_proxies, pick_best_proxies), but proxy_snapshot_stats deviates by leading with a noun and lacking a clear verb. Minor inconsistency that doesn't cause confusion.
Three tools is a well-scoped set for a proxy server: provide snapshot information, filter/listing, and best-pick selection. Each tool earns its place and the count fits the domain.
The tool surface covers the main workflows—viewing snapshot stats, listing proxies, and selecting the best ones. A refresh or test-proxy tool could be useful, but its absence is a minor gap that agents can work around.
Free remote MCP server for fetching public web pages through a rotating proxy pool.
Read-only MCP server for turva.dev's published service catalog, pricing and contact details. Five tools return JSON, including dated agent-readiness and security evidence with verification links. Connect over Streamable HTTP without an API key. The server answers questions about turva.dev and does not scan other websites or run audits.
Free OpenAI-compatible inference with signed provenance receipts and 3 focused MCP tools.
Trust, freshness, policy, and discovery layer for public MCP servers.
