DEV Community: Aethyn Team

Build a country-by-country price index with an AI agent (one MCP server, no scraping stack)

Aethyn Team — Sun, 12 Jul 2026 12:45:27 +0000

Give an AI agent a browser and it can read the web. But it reads the web from exactly one address — whichever machine it happens to be running on.

That's fine until the thing you're asking about is country-specific. Public prices, currency, regional availability, localized search results — all of it comes back through a vantage point the agent never chose and can't move. The agent doesn't error. It just confidently reports the wrong country's answer.

I wanted an agent that could say "check this from Germany, now from the UK, now from the US" — and then prove it actually did. So I built an MCP server for it, and this post is the walkthrough: we'll build a small country-by-country price index, driven entirely by tool calls.

The gap this fills

If you've used Microsoft's Playwright MCP, you know it's a genuinely good tool — it drives a browser properly. But its proxy is a launch flag: you set it when the server starts, and every call in that session goes out the same door. It wasn't built for per-task geography, and that's a reasonable design choice.

Hosted "scraping" MCPs solve geography by routing through their own cloud and handing you JSON. The geography is real, but it's opaque — you don't pick the exit, and you can't verify where a request actually landed.

What I wanted sat in between: a local browser, a residential exit, and the country as an argument on the tool call — plus a way for the agent to check the exit before trusting the page.

Setup (2 minutes)

It's an npm package. Add it to your MCP client config — claude_desktop_config.json for Claude Desktop, ~/.cursor/mcp.json for Cursor:

{
  "mcpServers": {
    "aethyn-browser": {
      "command": "npx",
      "args": ["-y", "aethyn-browser-mcp"],
      "env": {
        "AETHYN_USERNAME": "aethyn-XXXXX",
        "AETHYN_PASSWORD": "your-proxy-password",
        "AETHYN_DEFAULT_TIER": "premium"
      }
    }
  }
}

Chromium auto-installs on first run (~170 MB, once). The browser runs on your machine — nothing is hosted for you, and your credentials never leave your box.

Restart the client and the agent has 10 tools, all prefixed aethyn_:

Tool	What it does
`aethyn_launch_browser`	Open a proxied session in a chosen country
`aethyn_navigate`	Go to a URL
`aethyn_get_content`	Page content as text / html / markdown
`aethyn_snapshot`	Accessibility tree with `[ref=eNN]` handles
`aethyn_click` / `aethyn_type`	Interact by ref or selector
`aethyn_check_exit_ip`	Verify the exit through the session's proxy
`aethyn_new_identity`	Rotate to a fresh exit IP, clear cookies
`aethyn_close`	Close the session
`aethyn_list_countries`	Discover exit options at runtime

The build: a regional price index

The task: read a public product/pricing page from three countries and put the numbers side by side. Every step below is a real tool call the agent makes on its own.

Step 1 — let the agent discover its options

Rather than hard-coding a country list, the agent asks:

{ "tool": "aethyn_list_countries", "args": { "with_cities": false } }

This matters more than it looks: the agent can now plan a loop over countries it knows are actually available, instead of guessing and failing.

Step 2 — one sticky session per country

For each country, launch a session. The session argument is the important one — it's your task id, and reusing it pins the same exit IP for the whole task:

{
  "tool": "aethyn_launch_browser",
  "args": {
    "country": "de",
    "session": "price_idx_de",
    "lifetime_min": 10,
    "tier": "premium"
  }
}

Note the token is lifetime_min (1–1440 minutes, default 10), not "ttl". It's how long that exit stays pinned to your session. Launch returns a session_id, which every other tool takes.

Step 3 — verify before you trust (the step people skip)

This is the one I'd argue is the whole point:

{ "tool": "aethyn_check_exit_ip", "args": { "session_id": "..." } }

{ "ip": "…", "country": "DE", "city": "…", "org": "…", "is_residential": true }

It runs the check through the session's own proxy, so it tells you where the page you're about to load will actually come from. If the agent asked for de and the exit says something else, it can rotate and re-check instead of quietly reporting a German price it never saw.

(Fair warning: is_residential is a best-effort heuristic derived from the ASN/org — treat it as a signal, not a guarantee.)

Step 4 — read the page

{ "tool": "aethyn_navigate", "args": { "session_id": "...", "url": "https://example-store.com/pricing" } }
{ "tool": "aethyn_get_content", "args": { "session_id": "...", "format": "markdown" } }

markdown is usually the right format for feeding an LLM — it's the page, cleaned, without the script/style noise eating your context window.

Step 5 — close, repeat, aggregate

aethyn_close the session, then run the same sequence for uk and us with their own session ids. Because each country gets its own session, the identities never cross-contaminate.

What you actually type

The nice part is you don't orchestrate any of this by hand. You say:

"Using the aethyn-browser tools: list the available countries, then for de, uk, and us, open a sticky session, verify the exit IP is in the right country, load https://example-store.com/pricing, and pull the plan prices. Close each session when you're done. Put the results in a table with the currency, and flag any country where the exit IP didn't match what you asked for."

…and the agent runs the loop, checks its own work, and hands you the table. From there it's one more step to a chart or a nightly pipeline.

Two gotchas worth your time

1. The 407 that looks like a proxy failure but isn't.
AETHYN_DEFAULT_TIER defaults to premium, which uses HTTP port 2099. Elite uses 5499. If your account is Elite and you leave the default alone, the browser launches perfectly fine and then the proxy rejects auth with a 407. It looks like broken credentials; it's a port mismatch. Fix: set AETHYN_DEFAULT_TIER=elite, or pass tier: "elite" on the call.

Also note city and state targeting are Elite-only (port 5499). Country works on both tiers.

2. HTTP, not SOCKS5.
The server is HTTP-only by design — Chromium can't authenticate SOCKS5 proxies. If you've been burned by that before, this is why.

Bring your own proxy

It defaults to Aethyn, but it isn't locked to it. Point it at any HTTP proxy with PROXY_HOST, PROXY_PORT, PROXY_USERNAME, PROXY_PASSWORD, and a PROXY_USERNAME_TEMPLATE describing how your provider encodes targeting in the username:

PROXY_USERNAME_TEMPLATE="{username}-country-{country}[-city-{city}]-session-{session}-lifetime-{lifetime}"

[optional] segments drop out when empty. For a fixed proxy with no geo targeting at all, the template is just {username}.

Where this stays honest

Worth being direct about the boundaries, because the "agents + browsers" space is full of overclaiming:

Public data only. Respect robots.txt, rate limits, and each site's terms. "The agent can reach it" isn't "the agent should."
There is no CAPTCHA-solving tool, and none is planned. If a challenge fires, that's a signal to back off — not to fight it.
No login/credential-wall automation.
Nothing here auto-detects a block. If a page comes back looking wrong, the agent reads the content, judges it, and calls aethyn_new_identity. That's a deliberate choice — I'd rather the model make that call visibly than have the tool silently paper over it.
A residential exit fixes your network vantage point. It doesn't fix reckless pacing or a client that looks robotic in every other way.

Try it

npx -y aethyn-browser-mcp

Drop the config block in your MCP client, and your agent can pick a country on its very next tool call.

Full walkthrough + runnable examples: docs
The deeper writeup: Residential proxy browser MCP for AI agents
Source (MIT): github.com/aethynio/aethyn-browser-mcp · npm · Glama
Free account, no card: aethyn.io/signup

If you build something with it — or it breaks in an interesting way — I'd like to hear about it.

The Residential Proxy "Pool Size" Myth — Why 100M+ IPs Tells You Almost Nothing

Aethyn Team — Wed, 08 Jul 2026 16:03:38 +0000

Open any residential proxy provider's homepage and the first thing you see is a number. 50 million IPs. 100 million. "The largest residential network in the world." It's the industry's favourite headline — and one of the weakest predictors of whether your scraper actually works.

What the "pool size" number actually measures

That headline figure is almost always a cumulative count of unique IPs seen over a rolling 30-day window — not a live inventory. Three things follow, none of which make the marketing:

It's self-reported and unaudited. No standard for what counts as an IP, over what window. Two networks drawing on the same underlying supply can honestly print wildly different numbers.
The incentive only runs one way. Nobody ever chose a provider for a smaller pool. Every incentive pushes the number up — the exact condition under which a metric stops meaning anything.
Nobody publishes the number that matters: concurrent addresses available in your country, right now. That's a fraction of the headline and you'll never see it on a pricing page.

The headline IP count is a marketing decision, not a measurement.

Why the number can't predict success

The target never sees your pool. It sees one IP — the one you're using right now — and it scores that single address. Modern anti-bot systems judge a request on:

Is this a residential IP at all? The ASN instantly separates a real consumer ISP from a datacenter range. Datacenter IPs are blocked on sight.
What's this IP's reputation? Fraud-score databases flag addresses recently tied to abuse or automation.
Has this IP already misbehaved here? A recycled exit that hammered the target yesterday is treated very differently from a quiet one.
Is the story consistent? An IP geolocating to one country while headers/timezone claim another is a tell.

None of those is pool size. A huge pool full of recycled or flagged addresses performs worse than a smaller, clean one.

The mistake that ruins your data: trusting the status code

Internalise this before you benchmark anything: a 200 is not success. Modern defenses "soft-block" — a 200 with a CAPTCHA interstitial, a stripped decoy, or an empty shell. Measure success on content, not status:

import requests

PROXY = "http://USER:PASS@proxy.example.com:PORT"  # your provider's endpoint
proxies = {"http": PROXY, "https": PROXY}

def is_real_success(resp, positive_token):
    if resp.status_code != 200:
        return False
    body = resp.text.lower()
    block_signals = ["captcha", "unusual traffic", "access denied", "are you a robot"]
    if any(s in body for s in block_signals):
        return False
    return positive_token.lower() in body   # something ONLY a real page has

targets = [...]          # YOUR real URLs — not httpbin, not the vendor demo
TOKEN   = "add to cart"  # a string unique to a genuine page on YOUR target

ok = sum(is_real_success(requests.get(u, proxies=proxies, timeout=30), TOKEN)
         for u in targets)
print(f"content-verified success rate: {ok / len(targets):.1%}")

That percentage — success on your sites, verified on content — is the number the entire industry's marketing exists to distract you from.

Check what you're actually handed

Pull the exit IP and inspect it. This is where "big pool, dirty IPs" gets exposed in thirty seconds:

ip = requests.get("https://api.ipify.org", proxies=proxies, timeout=30).text
print("exit IP:", ip)

# Look that IP up in any public IP-reputation / fraud-score tool and confirm:
#   1. ASN is a consumer ISP (not AWS/GCP/a hosting provider)
#   2. it geolocates where you asked
#   3. it isn't already flagged for abuse

Spot-check the exits you're served — reputation beats raw count every time.

The one question a provider can't dodge

Ask where the IPs come from — and don't accept a non-answer. IPs from users who gave informed, opt-in consent behave like the real people they belong to and carry the reputation to match. IPs harvested from compromised devices are a botnet: already flagged, ethically indefensible, and a legal liability you inherit. A clean sourcing story is either documented or it isn't. A network that leads with a pool-size number and goes quiet on sourcing has told you which one it optimised for.

TL;DR — what to judge a network on

Success rate on your targets, verified on content (not status).
IP reputation — spot-check exits against a fraud-score tool.
Sourcing — consented/opt-in, not mystery pools.
Concurrency where you need it, not a global cumulative total.
Per-GB pricing you can forecast — if you need a sales call to see a price, you can't model cost.

Whatever wins that test is your provider. Pool size never enters the calculation — because it was never in the target's calculation either.

About Aethyn

I help build Aethyn — residential proxies built for engineers, not a marketing slide. One unified endpoint, country/city/session targeting encoded in the username, transparent per-GB pricing (€2.00/GB Premium, €4.50/GB Elite), and a free trial, no card. We deliberately don't lead with an IP-count — we'd rather you run the benchmark above on your own targets.

👉 Try it on your own targets: aethyn.io — free, no card

Originally published on aethyn.io.

Images via Unsplash (free license).