Giving an AI Agent Control of Your Proxy Account
How the Model Context Protocol lets an agent manage sub-users, endpoints and usage through an API token, and where to draw the line on spending.
- ai-agents
- tutorials
An agent that can read your proxy usage but not act on it is a dashboard with extra steps. The interesting version is the one that creates a sub-user when a job needs one, rotates the exit IP when a check fails, and pulls the traffic series when a run ends, without a human clicking through each screen.
The Model Context Protocol (MCP) is how that connection is standardized. If you already call the LightningBytes HTTP API with a token, this is the same account operations over a different transport, and it takes about a minute to wire up.
What MCP actually changes
Before MCP, every agent framework had its own way to describe a callable function. You wrote a wrapper, the framework discovered it, and the wrapper called your API. Move the agent to a different framework and the wrapper got rewritten.
MCP separates the two sides. A server publishes a set of tools with typed inputs and descriptions. A client, meaning the agent runtime, discovers those tools and calls them. The agent does not need a wrapper per API; it needs one client that speaks MCP.
For a proxy account the useful part is the tool boundary. The agent sees operations like "generate endpoints for this sub-user" rather than raw HTTP routes, and the server decides what each operation is allowed to touch.
One endpoint, one header
Remote MCP servers use the Streamable HTTP transport: a single URL that accepts JSON-RPC messages, with replies returned as JSON or a short server-sent event stream. The LightningBytes server is one path under the site:
https://www.lightningbytes.com/api/mcp
Every request carries the same bearer credential the HTTP API uses:
Authorization: Bearer YOUR_TOKEN
That is the whole transport contract. There is no separate MCP key to create and no second identity to keep in sync.
Why a static token is the right credential here
MCP's authorization rules push OAuth 2.1 for a specific case: when a server acts on behalf of a human who signs in through a browser and grants access to a third party. That flow exists to avoid handing a long-lived credential to an intermediary.
This case is different. The client is a token you created in your own dashboard, scoped to specific products and suppliers, revocable in one click, and rate-limited per token. The client is known to the server in advance. That is machine-to-machine, and a pre-registered credential is what the protocol expects for it.
If you later want a third-party platform to act on a customer's behalf without you issuing it a long-lived account token, that is the moment to reach for OAuth. Doing it now would add a browser consent step to an automation nobody is watching.
Scope is the control that matters
A token is not an account key with full access. It carries an explicit set of product and supplier pairs, and every tool call is checked against that list. A token scoped to residential on one supplier cannot generate a mobile endpoint, and an agent cannot widen the token's own reach.
This is the part worth getting right before you hand an agent anything. Create a token for the task, scope it to the products that task needs, and give the agent that token rather than a broad one. The blast radius of a leaked token is then the products you scoped, not the account.
Rotation is the cleanup path. Revoke the token on the API Tokens tab and the next call fails immediately; create a replacement with the same scope and update one line of the client config.
The boundary: operate, do not spend
There is a line between what an agent should do and what it should ask a person to do, and spending money is on the far side of it. An agent that can top up a balance unsupervised is one prompt injection away from buying traffic you did not intend.
The MCP server enforces that line. It exposes the operational surface, reading balances and usage, managing sub-users, generating and rotating endpoints, checking a proxy, and it exposes no tool that can buy traffic, change a plan or read an invoice. When the balance is low, the agent can return the link to the product's Add Traffic tab and a signed-in person completes the purchase.
The same boundary applies to the HTTP API. Both surfaces call one shared operations layer, so there is no second endpoint that quietly reopens what the other closes.
Wiring it up in Claude Code
Connect an agent client to the MCP server in one command:
claude mcp add --transport http lightningbytes \
https://www.lightningbytes.com/api/mcp \
--header "Authorization: Bearer YOUR_TOKEN"
Other clients take the same two values in their own config shape. The MCP tab of API Access in the dashboard has a copy-ready block for Claude Code, Claude Desktop, Cursor, VS Code and a generic client, each with the token placeholder in the right position.
A worked loop
A collection job that manages its own capacity looks roughly like this:
- Read the product balance to check there is traffic left.
- List sub-users and reuse one, rather than creating a new one per run.
- Generate a few endpoints, each with its own sticky session.
- Check each endpoint and rotate the ones that fail, which mints a fresh exit IP.
- Read the traffic series for the period when the run ends and record it.
Every step is an existing account operation. The agent is not doing anything the dashboard cannot; it is doing it without a person in the loop.
Failure modes and what they mean
An agent that hits an error should branch on the code, not on prose. The server returns the same envelope as the HTTP API.
| Code | Meaning |
|---|---|
401 unauthorized | The token is missing, revoked or expired |
403 scope_denied | The token is not scoped to that product or supplier |
403 no_entitlement | The proxy check needs an active plan with a spendable balance |
409 not_provisioned | The sub-user has no active proxy for that product yet, so retry shortly |
Two of those are configuration problems, not transient ones. If an agent reports scope_denied, the fix is the token's permissions, not a retry.
Where it fits next to the HTTP API
The HTTP API is still the right tool for a script you control: a cron job, a CI step, a data pipeline. MCP is the right tool when the caller is an agent deciding what to do next, because the tool descriptions are what let it choose.
They are not competing surfaces. Underneath, both run the same operations against the same account, so a sub-user created through an agent is the same row the dashboard shows, with the same allocation and the same credentials.
For the endpoint, the token table and the per-client setup, see Using the MCP Server. For the same operations over plain HTTP, see The API and API Tokens. If you are still deciding how much autonomy to hand an agent, AI Agents and Proxies covers the patterns, and the Proxy Checker is the quick way to confirm what any endpoint is actually exiting from.