Litport MCP

Litport MCP server

A Model Context Protocol server for the Litport API: inspect proxy tokens, usage, packages, and pay-per-GB pools/geo targeting; create, change, reissue the credentials of, and delete pay-per-GB proxies; change a token's location, rotation interval, or get a new IP; manage a package's allowed-IP list; build ready-to-use proxy connection URLs; and contact Litport support — directly from a coding agent or chat client.

The server cannot buy, renew, or cancel a package, or top up or move account balance. It can create and delete pay-per-GB proxies, which are live and billed per GB from the account balance as they are used. It can change a pay-per-GB proxy's label, on/off switch, pool, expiry, and traffic cap, and reissue the credentials of any proxy the account owns. A package's proxies can only be relabelled or have their credentials reissued; they end with their package. It can also change a token's location and rotation interval, request a new IP for a datacenter/ISP token, and add, remove, or set a package's allowed IPs.

Install and configure

Create an API key at litport.net/users/settings, then add the server to your MCP client's config with LITPORT_API_KEY in its env block.

The key is optional. Without one the server offers only the support tools and the three tools that need no account (explain_proxy_error, search_docs, get_doc).

Claude Code

claude mcp add litport -e LITPORT_API_KEY=lit_your_key_here -- npx -y @litportnet/litport-mcp

Or in .mcp.json:

{

"mcpServers": { "litport": { "command": "npx", "args": ["-y", "@litportnet/litport-mcp"], "env": { "LITPORT_API_KEY": "lit_your_key_here" } } } }

Claude Desktop

Add the same block to claude_desktop_config.json under mcpServers:

{

"mcpServers": { "litport": { "command": "npx", "args": ["-y", "@litportnet/litport-mcp"], "env": { "LITPORT_API_KEY": "lit_your_key_here" } } } }

Cursor

Add the same block to .cursor/mcp.json, or use Cursor's Settings → MCP → Add new MCP Server with command npx -y @litportnet/litport-mcp and LITPORT_API_KEY in the environment variables field.

Credential exposure — two options

Proxy tokens carry a username/password pair. Putting every password from list_tokens into the model's context by default is unnecessary exposure for a browse operation, so the server ships two ways to reach a real password:

Either way, nothing is ever permanently unreachable — the default just keeps bulk listings out of the model's context until a specific token is named. create_token and reissue_credentials return the one proxy's username and password the same way get_token_credentials does, by design: the real values are in the result, whatever LITPORT_MCP_REVEAL_CREDENTIALS says. update_token and delete_token never return credentials, so a label, cap or on/off change does not put a password into the model's context.

Tools

The read tools are annotated readOnlyHint: true, destructiveHint: false, idempotentHint: true. Every write tool documents in its own description whether it changes something and whether it is safe to repeat; get_new_ip, create_token and reissue_credentials are the exceptions (idempotentHint: false) — see below.

When the API refuses a call, the tool's error text holds the API's message, code, retryable, nextChangeAt and Retry-After (whichever it sent) and a docs link. retryable: true means the same call, sent again unchanged after the wait, can succeed and is safe to send; false means change something first, or, after an unclear failure of a call that is not safe to repeat, read the current state before deciding.

Contact support

Three tools reach Litport support through the support API.

Without `LITPORT_API_KEY` the conversation is a guest one. contact_support requires email (where we can reach you), and a guest conversation can answer general questions only. The access token that the API returns once stays in the server process for the session and is never shown to the model, so a guest conversation can be read only by the session that started it. Litport limits new guest conversations to 3 per hour and 10 per day per IP address.

With `LITPORT_API_KEY` the tools use your account's own conversation, where support can help with your orders and proxies. email is not used.

conversationId defaults to the conversation started or used most recently in the session. Replies are not pushed: get_support_replies returns pollAfterSeconds (30), so poll about that often. Messages are limited to 4,000 characters and 30 per conversation per 24 hours, and the API takes no attachments. Do not put API keys or proxy passwords in a message. You can also email mike@litport.net.

Token location, rotation, and new IP

set_token_location sends only the keys you give it — region/city for a datacenter/ISP token, or city/carrier for a mobile token — so give exactly one of those two shapes. With those, it is safe to repeat: resending the already-saved target is a no-op. A standard US Shared Mobile token allows this once per 48 hours; on a 409 CHANGE_LIMIT the error carries nextChangeAt and a Retry-After header, both of which the tool surfaces, so the model knows when it can try again instead of retrying blindly.

random: true (sent alone, without region, city, carrier or country; the tool refuses the mix without calling the API) moves the token to another location it can use right now: a different city when there is one, and for a mobile token otherwise another carrier in the same city. It is saved as the target like any other change, and the same waits apply. It is not safe to repeat blindly: each repeat moves the proxy again wherever no wait applies, so after a lost result read get_token_location first. 409 LOCATION_UNAVAILABLE means no other location is available; nothing changed.

set_rotation changes a token's rotation interval to one of its own rotation.options values, and answers NOT_SUPPORTED when rotation.changeable is false (e.g. a Multi-location mobile token, whose interval always follows its current phone).

get_new_ip requests a new IP for a datacenter/ISP token. On a static token it spends the weekly allowance and is not safe to blindly retry: call get_token_location first and check canChangeNow/nextChangeAt, because a second call inside the same week fails with CHANGE_LIMIT rather than returning a second new IP. If a call's result is lost or ambiguous, re-read get_token_location instead of calling it again.

On a rotating token it works at any time. The new IP is always different from the current one, and the token's automatic timer restarts. Two calls must be at least the type's shortest rotation interval apart (the smallest value in the token's rotation.options); inside that wait the call fails with CHANGE_LIMIT, nextChangeAt and Retry-After. LOCATION_UNAVAILABLE means no other IP qualifies right now: nothing changed, and the call still uses up the wait. After a lost result, get_token_location cannot confirm the change (its canChangeNow/nextChangeAt are about the location, not this wait). Calling again after Retry-After is harmless and just gives another new IP; a CHANGE_LIMIT right after a lost re