account-pool-mcp
This server manages a pool of test accounts, ensuring exclusive access per session via a lease-based system. Multiple agent sessions share the same SQLite database to coordinate account allocation, preventing conflicts.
lease_account— Check out an account exclusively from a named pool. Returns credentials and alease_token. Supports optional parameters:holder: a label for observability (e.g. a Jira ticket ID)ttl_seconds: custom lease lifetimewait_ms: how long to wait if the pool is empty (0 = fail fast)
release_account— Return a leased account to the pool using itslease_token. Idempotent: releasing an already-released or expired token returns success without error.renew_lease— Extend an active lease's TTL (heartbeat) to prevent auto-reclamation during long-running tasks. Returnsrenewed: falseif the lease has already expired, signaling you must re-lease.pool_status— View pool metrics (total, available, leased accounts) and per-account state without exposing credential values.Automatic lease reclamation — Expired leases are automatically reclaimed, so crashed sessions don't permanently block accounts.
Configurable pools — Define multiple account pools in a JSON config file; credentials can reference environment variables for secrets and are never logged or returned by
pool_status.CLI support — The same operations are available via
account-pool lease/release/renew/statusfor scripts and manual use.
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., "@account-pool-mcplease a test account from the pool"
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.
account-pool-mcp
An MCP server that hands out test accounts to agent sessions one at a time, so two sessions never end up logged into the same account.

The problem
When you run several agent sessions at once — say a few Claude sessions each driving their own Playwright browser — they all need to log in, and left alone they'll grab the same test account and step on each other. Two sessions on one account corrupt each other's state and your test results become meaningless. Picking a random account doesn't really help either: with 10 accounts and 5 sessions, a collision is already more likely than not.
The fix is to lease accounts. A session checks one out, uses it, and returns it. While it's checked out, no one else can be handed it.
Related MCP server: mcp-playwright-test
How it works
The server keeps a pool of accounts in a small SQLite database and gives them out one at a time.
Allocation happens inside a BEGIN IMMEDIATE transaction, so even if several sessions ask at the
exact same moment, they can't be handed the same account. Each lease has a TTL, so if a session
crashes without returning its account, it gets reclaimed automatically — there's nothing to clean up.
All of this happens in the background. The agent just asks for an account when it needs one; the broker decides which one it gets and guarantees no one else has it. There's no shared parent process — unrelated sessions coordinate purely through the database file.
Tools
lease_account(pool, holder?)— check out an account. Returns the account, its credentials, and alease_token. Hold it until you're done.release_account(lease_token)— give it back. Idempotent.renew_lease(lease_token)— extend the lease if your work runs long (a heartbeat).pool_status(pool?)— what's leased vs. free. Never returns credential values.
There's also a small account-pool CLI (lease / release / renew / status) over the same
database, for scripts and humans.
Setup
Want to see it first? bash examples/demo.sh runs a 60-second, no-install walkthrough — two sessions
lease different accounts, a third is correctly refused, and the pool recovers on release.
It's on npm, so there's nothing to clone or build.
Register it with your MCP client (e.g. .mcp.json) — npx fetches and caches it on first launch:
{
"mcpServers": {
"account-pool": {
"command": "npx",
"args": ["-y", "account-pool-mcp"],
"env": {
"APM_ACCOUNTS_FILE": "./accounts.json",
"APM_DB_PATH": "./account-pool.db"
}
}
}
}Then define your pools in accounts.json (an id and a credentials blob per account):
{ "pools": { "realtor": [
{ "id": "realtor_01", "credentials": { "username": "qa01@example.com", "password": { "env": "REALTOR_01_PW" } } }
] } }Want the CLI too? Run it ad-hoc with npx account-pool status, or install it on your PATH:
npm install -g account-pool-mcp # adds `account-pool` (CLI) and `account-pool-mcp` (server)Point every session's APM_DB_PATH at the same file — that shared file is how they coordinate.
Env var | Default | What it does |
|
| Pools + accounts to load on startup. |
|
| The SQLite file. Same path for every session. |
|
| How long a lease lasts before it's reclaimable. |
|
|
|
A credential value can be { "env": "VAR_NAME" } instead of a literal, so real secrets stay in the
environment and out of the accounts file.
Making your agent reach for it automatically
The server ships agent instructions in the MCP handshake — clients like Claude Code, Cursor, and
Windsurf inject them into context, so the agent knows to call lease_account before logging in
without being told each time. The tool descriptions reinforce it (lease is exclusive; you must
release).
For the most reliable pickup, also add a line to your project's own rules file
(CLAUDE.md, .cursor/rules/, .windsurfrules) so the agent's instructions and the server's
instructions agree:
## Test accounts
This repo has account-pool-mcp configured. Before logging into any test account in a QA or
Playwright run, call `lease_account` to check one out, and `release_account` when done.
Never hard-code, guess, or reuse an account — one account per session at a time.Security
These are test accounts, not a secrets vault. Credential values are never logged or returned by
pool_status — a redacting logger masks them, and all logs go to stderr so they can't corrupt the
MCP stream. Keep accounts.json and *.db out of git (only the .example files are committed). The
stdio server trusts whoever runs it locally, so don't point it at production credentials.
Limitations
Single host for now: coordination is through one SQLite file, so all sessions have to share a filesystem. The storage layer is isolated behind one module, so a Postgres or Redis backend could swap in later for multi-host coordination without changing the tools.
Maintenance
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ankitsxchdeva/account-pool-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server