What can you do with this server?

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 a lease_token. Supports optional parameters: * holder: a label for observability (e.g. a Jira ticket ID) * ttl_seconds: custom lease lifetime * wait_ms: how long to wait if the pool is empty (0 = fail fast) * release_account — Return a leased account to the pool using its lease_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. Returns renewed: false if 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/status for scripts and manual use.

How do I use account-pool-mcp?

1. Click on "Install 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., "@account-pool-mcp lease 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

by ankitsxchdeva

Overview Schema Related Servers Score Discussions

TypeScript

Local

account-pool-mcp

npm version npm downloads license Model Context Protocol Glama score

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.

account-pool-mcp demo: two sessions lease different accounts, a third is refused, the pool recovers on release

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: @kuramalab/mysupportdetails-mcp

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 a lease_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
`APM_ACCOUNTS_FILE`	`./accounts.json`	Pools + accounts to load on startup.
`APM_DB_PATH`	`./account-pool.db`	The SQLite file. Same path for every session.
`APM_DEFAULT_TTL_SECONDS`	`1800`	How long a lease lasts before it's reclaimable.
`APM_LEASE_WAIT_MS`	`0`	`0` = fail fast when the pool is empty; `>0` = wait this long for one to free up.

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.

Available Tools

4 tools

lease_accountA

Lease one account from the pool for browser login, EXCLUSIVELY, until you release it or the lease expires. No other session can be handed the same account while you hold it. You MUST call release_account with the returned lease_token when finished. If your task may run longer than the lease TTL, call renew_lease periodically to keep it.

ParametersJSON Schema

Name	Required	Description
`pool`	Yes	Which pool to lease from, e.g. "realtor" or "admin".
`holder`	No	A label for who is holding it (e.g. a Jira ticket id). Observability only.
`wait_ms`	No	Override the block-and-wait timeout for this call. 0 = fail fast on an empty pool.
`ttl_seconds`	No	Lease lifetime in seconds. Defaults to the server default TTL.

TDQS

A4.5/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 exclusivity, lease expiration, and the need to release/renew. Could mention auto-release on timeout, but overall transparent.

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 clear, front-loaded sentences with no wasted words. Efficiently conveys all necessary 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?

Given no output schema and no annotations, the description fully explains core behavior and required follow-up actions, making it complete for an agent to 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?

Schema coverage is 100%, baseline 3. The description adds workflow context (e.g., must call release_account) that goes beyond schema descriptions, enhancing parameter understanding.

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 'Lease one account from the pool for browser login, EXCLUSIVELY' and distinguishes from sibling tools like pool_status, release_account, and renew_lease.

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 states when to call release_account and renew_lease, providing clear usage guidance. However, does not explicitly state when not 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.

pool_statusA

Observability for the pools: totals, how many are available vs leased, and per-account state (free / leased / expired). Credential values are NEVER returned.

ParametersJSON Schema

Name	Required	Description	Default
`pool`	No	Limit to one pool. Omit for all pools.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description discloses key behavior: it is a read-only observability tool and assures credential values are never returned. This provides safety reassurance. However, it does not specify if results are real-time or cached.

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: the first clearly states the tool's purpose, the second adds an important security note. No unnecessary words; 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 no output schema, the description gives sufficient detail about returned data (totals, available vs leased, per-account state). Sibling context reinforces its role as a read-only status tool.

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

Parameters3/5

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

Schema coverage is 100% with a clear description for the 'pool' parameter. The tool description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.

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 provides observability for pools: totals, available vs leased, and per-account state. This distinctively sets it apart from sibling tools (lease, release, renew) which are mutating operations.

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 implies usage for checking pool status before mutating operations. It explicitly notes credentials are never returned, which is a safety guideline. However, it does not explicitly state when not to use or name alternatives.

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

release_accountA

Release a leased account so others can use it. Idempotent: releasing an already-released, expired, or unknown token returns released:false rather than erroring.

ParametersJSON Schema

Name	Required	Description	Default
`lease_token`	Yes	The lease_token returned by lease_account.

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description alone must disclose behavior. It does so by explicitly stating idempotency and the non-error behavior for invalid tokens. However, it does not mention side effects, auth requirements, or the success return format beyond 'released:false'.

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 with zero wasted words. The purpose is front-loaded, and the idempotency detail is added efficiently. Every sentence earns its place.

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 1-parameter tool, the description adequately covers the action and key behavioral trait (idempotency). It partially describes the return value, but omits the success case format. Given no output schema, a bit more detail on the return would improve completeness.

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

Parameters3/5

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

Schema coverage is 100% with a description for lease_token. The tool description adds no further parameter-specific information, so the baseline score of 3 applies.

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 action ('Release a leased account') and the purpose ('so others can use it'), distinguishing it from siblings like lease_account, pool_status, and renew_lease. The verb+resource combination is specific and unambiguous.

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 mentions idempotency (releasing already-released tokens returns false) which provides implicit guidance, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or context are given.

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

renew_leaseA

Extend (heartbeat) the current lease so long-running work is not reclaimed out from under you. If the lease already expired and was reclaimed (or the token is unknown), returns renewed:false — do NOT assume you still hold the account; call lease_account again.

ParametersJSON Schema

Name	Required	Description	Default
`lease_token`	Yes	The lease_token returned by lease_account.
`ttl_seconds`	No	New lease lifetime in seconds from now. Defaults to the server default TTL.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the failure condition (expired/reclaimed returns renewed:false) and advises against assuming continued ownership. It could mention the success response more explicitly, but it's adequately transparent.

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, front-loaded with the main purpose and then the conditional failure behavior. No unnecessary words; every sentence earns its place.

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 no output schema, the description covers the return behavior (renewed:false on failure) and the action to take. It could specify the success response more fully, but it's sufficient for a simple 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 input schema has 100% coverage, so baseline is 3. The description adds value by clarifying that lease_token comes from lease_account and that ttl_seconds defaults to server default, providing context 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?

The description clearly states the action ('Extend (heartbeat) the current lease') and the purpose ('so long-running work is not reclaimed out from under you'). It distinguishes from sibling tools like lease_account (acquiring) and release_account (releasing) by focusing on renewal.

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 explains when to use (to prevent reclamation) and what to do if renewal fails ('call lease_account again'). It provides clear context but does not explicitly list when not to use or name alternative tools, though siblings are distinct.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.1Jun 28, 2026
- First observedlease_account
- First observedpool_status
- First observedrelease_account
- First observedrenew_lease

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: leasing, checking pool status, releasing, and renewing. No functional overlap between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (lease_account, pool_status, release_account, renew_lease). No mixed conventions.

Tool Count5/5

Four tools cover the essential operations for an account pool (acquire, release, renew, status). The count is well-scoped and appropriate.

Completeness4/5

Core lifecycle is complete: acquire, release, renew, and monitor status. Missing operations like creating or deleting accounts, but those are likely out of scope for a pool manager.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

readme-canary
io.github.brkd-h1
Security research canary remote MCP server for owned-account testing.
Security Penetration Testing
11
Testiny Test ManagementOAuth
io.testiny
An MCP server that provides access to Testiny projects, test cases and test runs
Testing & QA Tools Project Management
2
Sensact
io.github.sensact-agents
An authenticated remote MCP server for user-owned devices and one-shot capability invocation.
OS Automation App Automation
2
Os Automation Mcp C
io.github.varvararatta
MCP server for OS Automation
OS Automation Command Line
2

Related MCP Servers

Playwright Pool
Browser Automation Testing & QA Tools
zbrooklyn-claude-labs
A
license
Not graded
quality
C
maintenance
MCP server for browser automation with shared authentication and built-in UI auditing.
Updated 3 months ago (2026-06-21 18:45 UTC)
MIT
@kuramalab/mysupportdetailsofficial
Browser Automation Testing & QA Tools
kuramalab
A
license
Not graded
quality
B
maintenance
An MCP server for QA and test automation that provides runtime switching between multiple browser profiles (Chromium, Firefox, WebKit) without restart, enabling cross-browser regression testing, multi-account testing, localization QA, and more.
Updated 2 months ago (2026-07-05 19:58 UTC)
18
MIT
mock-mcp-server
Testing & QA Tools Developer Tools
wontaeJeong
F
license
Not graded
quality
B
maintenance
A test MCP server that validates gateway connectivity, identity propagation, and provides mock tools for testing purposes.
Updated 2 months ago (2026-07-11 07:32 UTC)
-
testing-mcp
Testing & QA Tools Developer Tools
charlieNearform
F
license
Not graded
quality
B
maintenance
MCP server that enables AI agents to programmatically run tests, query results, and receive intelligent recommendations about test execution strategy.
Updated a month ago (2026-07-27 15:50 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

account-pool-mcp

The problem

How it works

Tools

Setup

Making your agent reach for it automatically

Security

Limitations

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@kuramalab/mysupportdetailsofficial

Latest Blog Posts

MCP directory API