Which integrations are available for this server?

Allows Hermes AI agents to use the BorrowIP MCP server for routing traffic through a mobile IP, providing tools for status checks, proxy retrieval, and URL fetching.

How do I use BorrowIP MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BorrowIP MCP Server fetch https://example.com using key BIP-a1b2c3" 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.

BorrowIP MCP Server

by wahyuzero

Overview Schema Source Related Servers Discussions Admin

Python

Remote

BorrowIP 📡

Borrow mobile IP for AI agents — route traffic through your phone's cellular connection via SSH reverse tunnel.

Zero infrastructure. Uses existing SSH (port 22). Works with any MCP-compatible AI agent.

How it works

📱 Phone (Termux)           🖥️ VPS                   🤖 AI Agent
────────────────            ─────────                ──────────
borrowip connect            borrowip-mcp             Hermes/Claude
  BIP-xxxx@vps-ip             (auto-started)             ↓
    │                             │                  borrowip_fetch()
    ├── SSH :22 ──────────────→  SSH :22                ↓
    │  pproxy :1080              SOCKS5 :10001       → cellular IP
    └── cellular ──→ internet ←──┘

Related MCP server: Novada Proxy

Quick Start

1. VPS: Install & configure AI agent

git clone https://github.com/wahyuzero/borrowip
cd borrowip && pip install -e .

Add to your AI agent config (e.g. Hermes config.yaml):

mcp_servers:
  borrowip:
    command: borrowip-mcp

When AI agent starts, ask: "check borrowip status" → shows your pair code.

2. Phone (Termux): Install & connect

# Install
curl -sL https://raw.githubusercontent.com/wahyuzero/borrowip/main/scripts/install-termux.sh | bash

# Setup (first time only) — choose key or password auth
borrowip init

# Connect using pair code from VPS
borrowip connect BIP-xxxxxx@your-vps-ip

3. Done!

"Fetch https://example.com using borrowip key BIP-xxxxxx"

AI agent routes traffic through your phone's cellular IP automatically.

For AI Agents (LLM)

See LLM_GUIDE.md for a complete reference written for AI agents.

Quick summary of the 3-step workflow:

borrowip_status() — check what's connected
borrowip_get_proxy() — get the socks5:// URL
borrowip_fetch(url) or browser_launch(proxy=<url>) — use the proxy

MCP Tools

Tool	Returns	Description
`borrowip_status()`	Text	Pair code + connected proxies with ports/IPs/alive status. Run first.
`borrowip_get_proxy(key?)`	`socks5://127.0.0.1:PORT`	Ready-to-use proxy URL. Use with browser tools.
`borrowip_fetch(url, key?)`	HTML/text	Fetch a URL through mobile proxy.
`borrowip_health_check(key?)`	`ALIVE`/`DEAD`/`STALE`	Fast 3s liveness test. Use when fetch fails.
`borrowip_check_ip(key?)`	IP address	Phone's external cellular IP.
`borrowip_list_proxies()`	Text	List all proxies with details.

Architecture

MCP Server (borrowip-mcp): Runs on VPS, auto-started by AI agent via stdio. Generates pair code, manages proxy connections.
Client (borrowip connect): Runs on Termux. Starts local SOCKS5 proxy (pproxy), creates SSH reverse tunnel, registers with pair code.

All traffic flows through SSH port 22 — no extra firewall rules.

Requirements

VPS: Python 3.10+, SSH on port 22, AI agent with MCP support (Hermes, Claude, Cursor, etc.)

Phone: Android + Termux, Python 3.10+, pproxy (pip install pproxy), SSH access to VPS (key or password)

Installation

VPS

git clone https://github.com/wahyuzero/borrowip
cd borrowip && pip install -e .

Termux

# Quick install
curl -sL https://raw.githubusercontent.com/wahyuzero/borrowip/main/scripts/install-termux.sh | bash

# Or manual
pkg install openssh python
pip install pproxy
git clone https://github.com/wahyuzero/borrowip
cd borrowip && pip install -e ".[client]"

Configuration

VPS (Hermes `config.yaml`)

mcp_servers:
  borrowip:
    command: borrowip-mcp

Termux (`~/.borrowip.toml`)

Created by borrowip init. Supports two auth methods:

Key auth:

[server]
host = "your-vps-ip"
user = "your-ssh-user"
ssh_key = "~/.ssh/id_ed25519"

Password auth:

[server]
host = "your-vps-ip"
user = "your-ssh-user"
ssh_password = "your-password"

Then just run borrowip connect (reads config automatically).

Auto-start (Termux)

# Install Termux:Boot from F-Droid
mkdir -p ~/.termux/boot/
echo 'borrowip connect &' > ~/.termux/boot/start-borrowip.sh
chmod +x ~/.termux/boot/start-borrowip.sh

Tunnel auto-reconnects on drop.

Security

SSH key or password auth
Pair code = identifier only; SSH credentials are the real auth
All traffic encrypted via SSH
SOCKS proxy bound to 127.0.0.1 only (not exposed to WiFi)
Pair code validated (prevents shell injection)

License

MIT

Available Tools

6 tools

borrowip_check_ipA

Check the external IP address of the mobile proxy.

Useful to verify the proxy is working and see which IP/cellular network is being used.

Args: key: Optional connection code. If omitted, uses first available proxy.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It only states the basic action and key parameter, but does not mention errors, rate limits, or what happens if proxy is unavailable.

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?

Three concise sentences plus arg description; no wasted words; front-loaded with main purpose.

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 simple tool with an output schema, the description covers purpose and parameter adequately, though it could mention return type (likely IP). Still, it's mostly complete.

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?

With 0% schema description coverage, the description explains the 'key' parameter's optionality and default behavior (uses first available proxy), adding value beyond 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?

Description clearly states the verb 'check' and the resource 'external IP address of the mobile proxy', and distinguishes from siblings like borrowip_fetch or borrowip_get_proxy by focusing on IP verification.

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?

Provides a clear use case ('verify the proxy is working and see which IP/cellular network is being used') but does not explicitly compare with sibling tools or state when not to use it.

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

borrowip_fetchA

Fetch a URL through the mobile proxy.

Use when a website blocks your server/VPS IP (Cloudflare, rate limits, geo-blocks). The request goes through the phone's cellular connection instead.

Args: url: The URL to fetch key: Optional connection code. If omitted, uses first available proxy.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so the description carries full burden. It mentions that the request goes through the phone's cellular connection and explains the key parameter's fallback behavior. However, it does not disclose potential errors, rate limits, or what happens if no proxy is available.

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?

The description is very concise with a clear structure: purpose, usage scenario, then parameter list. Every sentence adds value with no unnecessary words.

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?

Given the presence of an output schema, the description need not explain return values. It covers purpose, when to use, and parameters adequately. It could mention error handling, but the core information is present.

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 0%, but the description explains both parameters: url as the URL to fetch and key as an optional connection code defaulting to first available proxy. This adds significant meaning beyond the schema's basic titles.

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?

The description clearly states the tool fetches a URL through a mobile proxy, with a specific verb ('Fetch') and resource ('URL via mobile proxy'). This purpose distinguishes it from sibling tools like borrowip_check_ip or borrowip_list_proxies.

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?

The description explicitly says to use when a website blocks the server/VPS IP due to Cloudflare, rate limits, or geo-blocks. It does not mention when not to use or provide direct alternatives, but the context is clear.

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

borrowip_get_proxyA

Get a ready-to-use SOCKS5 proxy URL.

Returns the proxy URL string directly (e.g. 'socks5://127.0.0.1:10002'). Use this URL with any tool that accepts a proxy parameter:

CloakBrowser: browser_launch(proxy='socks5://127.0.0.1:10002')
curl: curl --socks5-hostname 127.0.0.1:10002
requests: requests.get(url, proxies={'https': 'socks5h://127.0.0.1:10002'})

Args: key: Optional connection code (e.g. BIP-xxxxxx). If omitted, uses first available.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden. It describes the return value and usage but does not explicitly confirm that this is a read-only operation, nor does it disclose potential side effects, authorization requirements, or error behavior (e.g., invalid key). The 'get' verb implies non-destructive action but is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, front-loading the main purpose, then providing return format and usage examples. It is concise without unnecessary repetition, though the examples could be slightly trimmed without loss of clarity.

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?

Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description adequately covers return type, usage, and parameter semantics. It lacks error handling details and limitations, but for a straightforward 'get' tool, it is mostly complete.

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

Parameters5/5

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

Schema coverage is 0%, but the description fully compensates by explaining the 'key' parameter: its optional nature, format (e.g., BIP-xxxxxx), and default behavior (uses first available). This adds significant meaning beyond the schema's type and default.

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?

The description clearly states 'Get a ready-to-use SOCKS5 proxy URL' with specific verb and resource. It distinguishes from sibling tools like borrowip_list_proxies (which lists proxies) and borrowip_fetch by focusing on obtaining a single usable proxy URL.

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?

The description provides usage examples for CloakBrowser, curl, and requests, and explains the 'key' parameter behavior. However, it does not explicitly state when to use this tool versus alternatives like borrowip_list_proxies or borrowip_fetch, nor does it mention scenarios where the tool should not be used.

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

borrowip_health_checkA

Quick liveness check — is the proxy tunnel actually working?

Tests if the SOCKS5 port is open AND can reach the internet. Much faster than borrowip_fetch (3s timeout vs 30s).

Args: key: Optional connection code. If omitted, checks first available proxy.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the behavioral traits: tests SOCKS5 port openness and internet reachability, has a 3s timeout, and is non-destructive. The output schema exists so return format explanation is not required. It could mention if the check affects proxy state, but it is likely read-only.

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?

The description is extremely concise: three lines of purpose and behavior, plus a separate Args section. Every sentence earns its place with no fluff. The key information is front-loaded.

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?

Given the simplicity of the tool (1 optional parameter, no nested objects, output schema exists), the description covers the essential aspects: what it tests, timeout, comparison to a sibling, and parameter behavior. It does not fully explain error conditions or preconditions, but it is adequate for a health-check tool.

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?

The schema provides no description for the key parameter (0% coverage), so the description must compensate. It adds meaning by stating 'Optional connection code' and 'If omitted, checks first available proxy', which clarifies the parameter's role and default behavior. More detail on the format of the connection code would improve.

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?

The description clearly states it is a 'quick liveness check' for the proxy tunnel, testing if the SOCKS5 port is open and can reach the internet. It distinguishes itself from sibling borrowip_fetch by noting it is much faster (3s vs 30s timeout), and the verb 'check' combined with 'proxy tunnel' makes the resource specific.

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?

The description explicitly states it is faster than borrowip_fetch, guiding agents to use this for quick health checks instead. It also explains when to use the optional key parameter versus omitting it. However, it does not provide guidance for when to use other siblings like borrowip_check_ip or borrowip_status, so it lacks complete exclusion criteria.

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

borrowip_list_proxiesA

List all connected mobile proxies with details.

Returns one line per proxy: code, SOCKS5 URL, IP, age, alive status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses output format but does not mention rate limits, authentication needs, or side effects. For a simple read-only list, basic transparency is adequate but could be improved.

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: first states purpose, second details output format. No fluff, front-loaded key information.

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

Completeness5/5

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

Tool is simple (list all connected proxies). Output schema exists, and description summarizes return fields. No missing context for intended use.

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?

Input schema has zero parameters (100% coverage trivially). Baseline 4 for no parameters. Description adds output field explanation, providing meaning beyond 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?

The description clearly states 'List all connected mobile proxies with details' and enumerates specific fields (code, SOCKS5 URL, IP, age, alive status). It distinguishes from siblings like borrowip_get_proxy and borrowip_check_ip by focusing on listing all proxies.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives (e.g., borrowip_get_proxy for a single proxy). No when-not-to-use or prerequisite information.

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

borrowip_statusA

Check BorrowIP status. ALWAYS run this first.

Returns the pair code (for connecting a phone) and lists connected proxies with their SOCKS5 ports.

Example output: BorrowIP Status Pair code: BIP-ab12cd Proxies: 1 connected BIP-xw9su6 | socks5://127.0.0.1:10002 | IP: 140.213.141.84 | alive

If no proxies: tells you the exact Termux command to run.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

No annotations exist, so description fully carries burden. It details exactly what is returned (pair code, proxy list, Termux command if none) and includes an example output, ensuring full transparency of behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise with key info front-loaded. Example output adds value but is not excessive. Could be slightly more terse, but overall well-structured.

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

Completeness5/5

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

Given zero parameters and presence of output schema, the description fully covers what the tool does and what it returns, including edge cases like no proxies. Complete for its complexity.

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?

No parameters exist, so baseline is 4. Schema coverage is 100% (empty schema). Description adds no parameter info, but none is needed.

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?

The description clearly states the tool checks BorrowIP status, returns pair code and connected proxies with SOCKS5 ports, and distinguishes itself by being the first step to run. It differentiates from siblings like borrowip_fetch or borrowip_get_proxy by emphasizing its role as an initial status check.

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?

Explicitly says 'ALWAYS run this first', providing clear usage guidance. While it doesn't list alternatives, the context of sibling tools and the 'first' directive effectively communicates when to use this tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Jun 27, 2026
- First observedborrowip_check_ip
- First observedborrowip_fetch
- First observedborrowip_get_proxy
- First observedborrowip_health_check
- First observedborrowip_list_proxies
- First observedborrowip_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-27 19:35 across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: checking IP, fetching, getting proxy URL, health check, listing, and status. No two tools perform the same function, making it clear for an agent which tool to use.

Naming Consistency3/5

All tools start with 'borrowip_', but the suffix patterns vary: verb_noun (check_ip, get_proxy, list_proxies), verb only (fetch), noun (status), and compound noun (health_check). This inconsistency could confuse an agent slightly.

Tool Count5/5

With 6 tools, the set is well-scoped for a proxy management server. Each tool serves a necessary function without being too few or too many.

Completeness4/5

The tools cover core proxy workflows: connecting (via status), listing, validating (check_ip, health_check), and using (fetch, get_proxy). Missing a dedicated disconnect tool is a minor gap but agents can work around it.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Route6 — Agent Network Identity
me.route6
Gives AI agents a public IPv6 identity, hostname, port forwarding, web fetch, team mesh. Free tier.
Networking & Infrastructure Agent Orchestration
2
mcp A
ai.foura
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
Web Scraping Browser Automation
434
scrapeless-mcp-server
io.github.scrapeless-ai
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Browser Automation Web Scraping Search
1169
HasData A
com.hasdata.mcp
Direct access to 60+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.
Browser Automation RAG Systems Web Scraping
632

Related MCP Servers

ProxyClaw MCP Server
Browser Automation Web Scraping Networking & Infrastructure
Iploop
A
license
A
quality
D
maintenance
Routes web requests through 175M+ residential IPs across 195+ countries, enabling AI to bypass geo-restrictions and anti-bot systems.
Updated 5 months ago (2026-04-26 06:37 UTC)
4
32 npm
1
MIT
Novada Proxyofficial
Browser Automation Web Scraping Agent Orchestration
NovadaLabs
A
license
Not graded
quality
C
maintenance
Enables AI agents to route HTTP requests through millions of real residential IPs, bypassing anti-bot systems and geo-targeting by country or city.
Updated 3 months ago (2026-06-18 15:32 UTC)
4
MIT
@proxies-sx/mcp-server
Networking & Infrastructure Autonomous Agents
bolivian-peru
A
license
A
quality
C
maintenance
Enables AI agents to autonomously buy and operate mobile proxies via MCP, supporting both API key and on-chain USDC payments for tasks like port creation, IP rotation, and traffic management.
Updated 2 months ago (2026-07-25 07:34 UTC)
44
16 npm
MIT
atheris-mcp
Browser Automation Web Scraping
atheris-ee
A
license
Not graded
quality
C
maintenance
Enables agents to autonomously route traffic through real 4G/5G mobile and residential IPs by country, with tools to check live proxy stock, obtain ready-to-use proxy URLs, and monitor remaining data usage.
Updated 2 months ago (2026-07-16 20:21 UTC)
25 npm
MIT

BorrowIP 📡

How it works

Quick Start

1. VPS: Install & configure AI agent

2. Phone (Termux): Install & connect

3. Done!

For AI Agents (LLM)

MCP Tools

Architecture

Requirements

Installation

VPS

Termux

Configuration

VPS (Hermes config.yaml)

Termux (~/.borrowip.toml)

Auto-start (Termux)

Security

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Novada Proxyofficial

VPS (Hermes `config.yaml`)

Termux (`~/.borrowip.toml`)