DoubleData MCP

Export proxy list file

export_proxy_list

Read-only

Generate proxy list files for scrapers and tools with rotating or sticky-session lines in a chosen format and owner-only permissions.

Instructions

Write a proxy list file (one proxy per line) for scrapers and tools: N sticky sessions with unique IDs or rotating lines, in the chosen format. The file contains the real password and is created with owner-only permissions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "export_proxy_list"
  }
}

Input Schema

Name	Required	Description	Default
`city`	No	Exit city within the country, e.g. 'New York' (residential/datacenter only).
`path`	No	Relative output path inside the export directory.
`count`	No
`format`	No		url
`sticky`	No	Give each line its own sticky session.
`country`	No	Two-letter exit country, e.g. us, de, gb.
`gateway`	No	Entry gateway closest to you. It does not choose the exit country.	eu
`session`	No	Sticky session ID. Reuse it to keep the same exit IP.
`protocol`	No		http
`username`	No	Credential to use. Defaults to DOUBLEDATA_PROXY_USERNAME or the first enabled credential of proxy_type.
`proxy_type`	No	Product to use when no username is given. Defaults to residential.
`ttl_minutes`	No	Sticky session lifetime, 1-120 minutes. Requires session.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely new behavior: the output contains the real password and the file is written with owner-only permissions, which is exactly the kind of risk context an agent needs before calling. It leaves unstated whether an existing file at 'path' is overwritten and where the export directory lives, keeping it below a 5.

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?

Two dense sentences, with the operation and line layout front-loaded and the security note second. No filler or restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, no-output-schema tool that emits a credential-bearing file, the definition covers what is written and its permissions but omits overwrite semantics and what is returned (path or content). Adequate to call correctly, not complete for an agent that must reason about side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the baseline is 3; the description goes beyond it by explaining that count maps to N lines each with a unique sticky session ID (or rotating lines when sticky is off) and that output is one proxy per line in the chosen format. It adds no guidance for path, gateway, or protocol, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Strong verb+resource: 'Write a proxy list file (one proxy per line)' states exactly what is produced, and it distinguishes the two output modes ('N sticky sessions with unique IDs or rotating lines'). It stops short of naming build_proxy_config, the closest sibling, so the agent must infer which produces a file versus a config object.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'for scrapers and tools' gives a general audience but no explicit when-to-use versus build_proxy_config or proxy_request. The sticky/rotating phrasing implies the choice governed by the sticky parameter, but no exclusions or prerequisites (e.g., needing a credential or export directory) are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.