DoubleData MCP

Check proxy exit IP

check_exit_ip

Verify proxy settings by returning the exit IP, country, city, and network seen by a public IP echo service, so you can confirm targeting and sticky sessions before running a larger job.

Instructions

Verify a proxy configuration by returning the exit IP, country, city and network seen by a public IP echo service. Use it to confirm targeting and sticky sessions work before a larger job.

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": "check_exit_ip"
  }
}

Input Schema

Name	Required	Description	Default
`city`	No	Exit city within the country, e.g. 'New York' (residential/datacenter only).
`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		https
`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.9/5.0

Behavior3/5

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

Annotations already flag readOnlyHint=false, openWorldHint=true and idempotentHint=false; the description usefully explains the external dependency by naming the public IP echo service that is contacted. It does not say whether the call consumes proxy traffic/quota, what authentication is required (the username default chain lives only in the schema), or that non-sticky calls may land on a different IP each time.

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 sentences, front-loaded with the action and the returned fields, with no redundant restatement of the title or schema. Every clause carries information.

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?

With 8 optional parameters and no output schema, the description compensates by enumerating the returned fields and framing the call as a pre-flight check, which is sufficient to invoke it correctly. The remaining gap is the absence of any note on credentials or traffic consumption for an open-world call.

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 already 88%, so the baseline is 3, but the description adds meaning by connecting 'targeting' to the country/city parameters and 'sticky sessions' to session/ttl_minutes, telling the agent what to vary when verifying. It adds no syntax detail, which is acceptable given the rich schema.

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?

The description gives a specific verb and resource ('Verify a proxy configuration') and states exactly what is returned: exit IP, country, city and network as observed by a public IP echo service. That is enough for an agent to tell this apart from proxy_request, which actually performs traffic rather than echoing the exit identity, although no sibling is named explicitly.

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

Usage Guidelines4/5

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

'Use it to confirm targeting and sticky sessions work before a larger job' supplies a clear pre-flight context and ties usage to the country/city and session parameters. There is no explicit when-not or named alternative (e.g. proxy_request for real traffic), so it stops short of a 5.

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