DoubleData MCP

Send HTTP request through proxy

proxy_request

Fetch any HTTP URL through rotating residential, datacenter, or mobile proxies with country, city, and sticky-session targeting; returns status, headers, and body, with optional file save.

Instructions

Fetch a URL through the DoubleData proxy network with optional country/city targeting and sticky sessions. Returns status, key headers and the body (HTML converted to Markdown by default, truncated to a safe size). Use save_to to download the raw response to a file. Consumes proxy traffic.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "proxy_request"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Destination http(s) URL.
`body`	No	Request body for POST/PUT/PATCH.
`city`	No	Exit city within the country, e.g. 'New York' (residential/datacenter only).
`method`	No		GET
`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
`headers`	No	Extra request headers.
`save_to`	No	Save the full response body to this relative path inside the export directory.
`session`	No	Sticky session ID. Reuse it to keep the same exit IP.
`protocol`	No	Connection to the proxy: https (port 9999, encrypted) or http (port 7777).	https
`username`	No	Credential to use. Defaults to DOUBLEDATA_PROXY_USERNAME or the first enabled credential of proxy_type.
`max_chars`	No	Maximum characters of body returned to the agent.
`proxy_type`	No	Product to use when no username is given. Defaults to residential.
`timeout_ms`	No
`ttl_minutes`	No	Sticky session lifetime, 1-120 minutes. Requires session.
`response_format`	No	markdown simplifies HTML; text returns the body as-is; raw returns only metadata unless saved.	markdown

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already flag openWorld=true and destructive=false, so the bar is lower, yet the description adds real context: what comes back (status, key headers, body), default HTML-to-Markdown conversion, truncation to a safe size, raw-save behavior, and that calling consumes proxy traffic. Missing permission or error-mode detail, but this is substantive disclosure beyond the annotations.

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?

Four tight sentences, front-loaded with the action and scope, then return shape, the save option, and the cost warning. No filler and nothing important buried.

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

Completeness4/5

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

For a 16-parameter tool with no output schema, the description covers the return payload, truncation, raw-save semantics, and traffic cost, which is most of what an agent needs. Method/headers/timeout behavior and failure modes are left to the schema, leaving a small gap.

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 88% so the baseline is 3, but the description adds behavioral meaning the schema does not: markdown is a conversion of HTML, raw returns only metadata unless saved, save_to writes the raw untruncated body, and session enables sticky exit IPs. That goes beyond field-level definitions, though several parameters (method, headers, timeout) are left entirely to the schema.

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: fetching a URL through the DoubleData proxy network with targeting and sticky sessions. An agent can distinguish this from credential, config, and account siblings 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 Guidelines3/5

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

It tells the agent that save_to is for downloading raw responses and that traffic is consumed, which implies when to care. But there is no explicit when-to-use-vs-alternative guidance against siblings like check_exit_ip, and no exclusion or prerequisite text.

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