Click on "Install 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., "@DataImpulse MCP Proxy Fetch example.com from the US proxy and return the text"
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.
Use DataImpulse residential proxy targeting from Claude Code or OpenCode without routing the rest of your system through a proxy. This educational MCP server provides bounded access to public HTTP(S) pages with best-effort SSRF safeguards.
Never configureHTTP_PROXY or HTTPS_PROXY globally. This server creates a DataImpulse ProxyAgent for each MCP request, so other terminals, editors, package managers, and MCP servers remain unaffected.
Prerequisites: Node.js 22.19.0 or later and a DataImpulse account with a username and password.
git clone https://github.com/Gentleman-Programming/dataimpulse-mcp.git
cd dataimpulse-mcp
npm installThe server reads only DI_USER and DI_PASS at runtime. Copy .env.example for local reference if useful, but configure credentials in your MCP client rather than committing a .env file.
Related MCP server: Novada Proxy
Run this from the checked-out repository, replacing the placeholders and path:
claude mcp add di-proxy --scope user \
--env DI_USER=your_dataimpulse_username \
--env DI_PASS=your_dataimpulse_password \
-- node /absolute/path/to/dataimpulse-mcp/index.js--scope user makes the server available to your local Claude Code user. Claude Code stores this configuration, including the supplied credentials, in ~/.claude.json; protect that file and never commit or share it.
Add this entry to your OpenCode configuration, replacing the placeholders and absolute path:
{
"mcp": {
"di-proxy": {
"type": "local",
"command": ["node", "/absolute/path/to/dataimpulse-mcp/index.js"],
"environment": {
"DI_USER": "your_dataimpulse_username",
"DI_PASS": "your_dataimpulse_password"
}
}
}
}Restart OpenCode after saving the configuration so it starts the stdio server with the new environment.
fetch_pageFetches a public HTTP(S) page through DataImpulse. By default, it returns cleaned, readable text; set raw to true when the caller needs HTML.
Parameter | Required | Description |
| Yes | Public HTTP(S) URL, up to 2,048 characters. URLs with credentials and local/private destinations are rejected. |
| No | Two-letter ISO country code, such as |
| No | City token using letters, numbers, hyphens, or underscores. Requires |
| No | Stable session token using letters, numbers, hyphens, or underscores. |
| No | Set to |
{
"url": "https://example.com",
"country": "US",
"session": "research-001"
}{
"url": "https://example.com",
"country": "ES",
"city": "Madrid",
"raw": true
}check_exit_ipChecks the public exit IP selected by DataImpulse without fetching a target page. Use it to verify country or session targeting before a workflow.
Parameter | Required | Description |
| No | Two-letter ISO country code. |
| No | Session token to check a stable route. |
{
"country": "US",
"session": "research-001"
}Targeting practices
Use an explicit country for geo-specific content.
Reuse the same session across multi-step flows that need a consistent route.
Use city only when necessary: DataImpulse charges city targeting at double the normal rate.
Avoid blind retries. Change one variable, observe the result, and stop when the target rejects the request.
Error actions
Response | Meaning | Action |
| DataImpulse traffic credit is exhausted. | Add traffic credit, then retry. |
| The account has more than 2,000 active connections. | Reduce concurrent requests, then retry. |
| No proxy IP matches the requested targeting. | Remove city targeting and retain only the country. |
| The destination blocked the request. | Try another country or a fixed session once; respect the site's rules. |
| The destination applied rate limiting or anti-bot controls. | Try one new session or another country once. If it persists, access the target site directly or use another search engine. Do not retry blindly. |
Best-effort SSRF safeguards: every initial URL and redirect target is checked for an HTTP(S) scheme, no credentials, a permitted hostname, and public-only local DNS resolution. Local, private, metadata, credentialed, and mixed-resolution hosts are rejected, with a maximum of 10 redirects.
Remote proxy resolution: ProxyAgent sends the hostname to the remote proxy, which performs its own DNS resolution. DNS rebinding or split-horizon DNS can therefore differ from local validation. Do not use this tool with untrusted URLs in high-security environments; if exposing it to untrusted users, prefer a domain allowlist.
Credentials: DI_USER and DI_PASS are read only at startup and are never logged or returned to MCP clients.
Response bounds: bodies with an advertised Content-Length above 1,048,576 bytes (1 MiB) are rejected before reading; streaming bodies are cancelled once they exceed that limit. Successful and error output is then limited to 60,000 characters.
Timeout: every request has a 45-second timeout; each per-request proxy agent is destroyed after use.
This project is licensed under the MIT License.
Return the public IP assigned by the current DataImpulse proxy targeting.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ||
| session | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Return the public IP' without mentioning whether the tool makes an outbound request, what the response format is, how the optional parameters affect behavior, or any error conditions. The lack of detail leaves the agent uncertain about side effects, safety, and failure modes.
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 immediately states the core function. There is no redundant fluff, and the key information (what it returns and under what context) is front-loaded.
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 2 optional parameters, no output schema, and no annotations, the description is far too minimal. It omits parameter roles, usage context, response structure, and behavioral details. For a tool that likely makes a network request, this is severely incomplete and leaves the agent guessing.
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 description coverage is 0%, so the description must compensate. It does not mention the 'country' or 'session' parameters at all, their purpose, or how they influence the result. The parameter names are mildly suggestive but no real semantics are provided beyond the schema patterns.
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 tool's function: returning the public IP assigned by the current DataImpulse proxy targeting. The verb 'Return' is specific, the resource is clear (the exit IP), and it distinguishes itself from sibling tool fetch_page, which presumably fetches web content.
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 when to use the tool (to check the current proxy exit IP), but it does not explicitly state when to use it versus alternatives, nor does it provide any exclusions or prerequisites. The context 'current DataImpulse proxy targeting' suggests verification for proxy setup, but this is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public HTTP(S) page through a DataImpulse residential proxy.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | ||
| url | Yes | ||
| city | No | ||
| country | No | ||
| session | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only mentions the proxy but does not explain response format, redirect handling, error behavior, or authentication requirements. The clarity that it fetches 'public' pages is minimal and does not set expectations for the agent.
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 with no unnecessary words. It is front-loaded with the core action and proxy context, making it efficient. However, it could be expanded with behavioral details without sacrificing conciseness.
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 absence of annotations, output schema, and parameter descriptions, the tool description is insufficiently complete. It does not provide enough context for an AI to understand return values, parameter effects, or how it differs from 'check_exit_ip' in practical scenarios.
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 has 5 parameters with 0% description coverage, and the description does not mention any parameter meaning or usage. It fails to clarify the purpose of 'raw', 'city', 'country', or 'session', leaving the agent without any semantic guidance beyond variable names.
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 tool fetches a public HTTP(S) page through a DataImpulse residential proxy, using the specific verb 'Fetch' and a well-defined resource. It distinguishes itself from the sibling tool 'check_exit_ip' by focusing on page retrieval rather than IP inspection.
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 sibling 'check_exit_ip' or any alternatives. It lacks contextual cues such as 'use this when you need to retrieve web content' or exclusions like 'not for authenticated pages'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have completely distinct purposes: one fetches a page through the proxy, the other reports the proxy's exit IP. There is no overlap or ambiguity between them.
Both tool names follow a consistent verb_noun pattern: 'fetch_page' and 'check_exit_ip'. This makes the API predictable and easy to learn.
With only 2 tools, the server feels slightly thin for a typical MCP server, but the scope is narrow and focused on basic proxy operations. The count is borderline but not excessive.
The server covers the essential proxy workflow: fetching a page and verifying the proxy IP. Minor gaps exist, such as no session management or request customization, but the core purpose is adequately served.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
The most accurate web access API. Stop getting blocked.
Read any web page as clean Markdown for AI agents: fetch, search, metadata, links. SSRF-safe.
Scrape, crawl, map and extract the web. Pay per call in USDC, no account or API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Gentleman-Programming/dataimpulse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
