Skip to main content
Glama
Sign In
CDPM

CDPM

by IGELHARINE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Launch slot

browser_launch

Launch one or more numbered Chrome slots over CDP shared by Claude sessions and subagents; attaches if already running. Start one or many with slot, slots, or count.

Instructions

Starts slot Chrome. Call only when the user explicitly asks (other tools never start a closed slot). Without slot, uses the lowest free slot. If already running, just attaches. The user decides windowed (visible) vs headless (hidden): headless: true only if they say "headless/hidden". If unstated, don't guess; ask first, then call with headless. Starting a closed slot without headless only returns a confirmation request. Start several slots at once with slots (list) or count (lowest first). For different jobs per slot, after launching give each slot its own subagent in parallel.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "browser_launch"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoSame start URL for every launched slot (e.g. "https://mail.google.com"). For per-slot or partial URLs use urls instead. Pass it when the start page is known so subagents need no separate navigation
slotNoOne slot to start (1-30). Omit if the user gave no number → lowest free slot
urlsNoPer-slot start URLs, paired in slots order (count: launch order). "" = blank tab. E.g. slots [1,2], urls ["https://www.wehago.com", "https://test.igel.kr"] → 1 opens wehago, 2 opens test.igel.kr
agentNoYour display name, shown to other agents. Subagents must always set it. Default "claude-1e1b".
countNoWhen the user gives only a count ("start 3"): starts that many free slots, lowest first
proxyNoOnly when the user asks for a proxy (never otherwise). As given: "1.2.3.4:8080", "http://user:pass@host:port", "socks5://host:port", "host:port:user:pass", etc. Applies to all launched slots, first launch only
slotsNoSlot numbers to start at once (e.g. [1,2,3]), lowest first
proxiesNoPer-slot proxies, paired in slots order (count: launch order)
headlessNofalse = windowed (visible), true = headless (hidden). true only if the user says "headless/hidden/no window", false for "visible/headful". If unstated, omit and ask first (no guessing). Applies only on first launch

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.10
    • changedInput schema / properties / agent / description
      Previous value: -"Your display name, shown to other agents. Subagents must always set it. Default \"claude-68d9\"."New value: +"Your display name, shown to other agents. Subagents must always set it. Default \"claude-1e1b\"."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose non-obvious traits: attach-instead-of-relaunch on a running slot, a bare confirmation request when headless is unstated for a closed slot, and that proxy/headless apply only on first launch. It stops short of describing the response shape or failure modes, which is the remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and the critical gating rule, then flows to multi-slot and subagent orchestration. Slightly dense and it duplicates the headless guidance already present in the schema, but every sentence still carries decision-relevant content.

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 nine-parameter, zero-annotation, no-output-schema tool, the description covers launch semantics, the headless decision, multi-slot batching, and post-launch subagent orchestration. What an agent gets back and how failures surface are left implicit, keeping it just under complete.

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 description coverage is 100%, so the schema already documents all nine parameters, including the slot/urls pairing example and the port-minus-14049 rule. The description largely restates headless/count/slots semantics rather than adding new meaning, so baseline 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?

States a specific verb+resource ("Starts slot Chrome") and immediately clarifies that an already-running slot is merely attached to, distinguishing launch from close/status/tab operations among the siblings. An agent can tell exactly what activation does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gates invocation: "Call only when the user explicitly asks (other tools never start a closed slot)", and prescribes the headless decision procedure (true only if user says headless/hidden, otherwise ask before calling). Names the alternatives (slots/count for multi-launch) and the follow-up pattern (per-slot subagents).

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

Deploy Server

Other Tools