Maintain a warm pool of browser tabs ready to acquire or release, scaling to a set size and auto-growing by one when empty for parallel agent workflows.
Maintain a warm pool of N tabs always ready to be acquired.
Grows or shrinks to size. Acquire/release via browser_pool_acquire and
browser_pool_release. Auto-grows by one if you acquire from an empty pool.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | about:blank | |
| size | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the auto-grow-by-one rule when acquiring from an empty pool, but is silent on what shrinking does to already-open tabs (likely closing them), whether in-use tabs are protected, and what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core purpose before the acquire/release routing and the auto-grow edge case. Nothing is redundant, though the fragmented line breaks make it slightly less polished than a single flowing paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a pool-management tool with no annotations, no output schema, and a 0%-documented parameter set, the description covers the concept and cross-references siblings but omits the url parameter, the effect of shrinking on live tabs, and return behavior. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it only partially does: it explains `size` ('grows or shrinks to `size`') but never documents `url` (default about:blank), leaving an agent unsure what URL pooled tabs open. One of two parameters is meaningfully explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it maintains a warm pool of N tabs ready to be acquired, and explicitly routes acquire/release operations to the browser_pool_acquire and browser_pool_release siblings. An agent can distinguish this pool-management tool from the acquire/release tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the alternative tools (browser_pool_acquire, browser_pool_release) and the division of labor, so the agent knows to call this one to size the pool and the siblings to draw from it. It does not state when NOT to use it (e.g., use browser_new_tab for a one-off tab), so it falls short of the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.