Skip to main content
Glama

stop-all-simulator-servers

Stop simulator-server processes, debuggers, profilers, and inspectors for specified device IDs, or all devices machine-wide when omitted. Frees sockets and ports for a clean teardown.

Instructions

Stop the services a device owns - simulator-server processes (iOS + Android), native devtools, the iOS accessibility service, TV-control daemons, Chromium CDP sessions, screen recordings, native profiler sessions, and JS-runtime debugger sessions along with the network inspectors and React profiler sessions that ride on them - freeing their spawned processes, sockets and ports. Call this when your session ends or the user says they are done. PASS devices with the device ids this session used — one tool-server serves every agent, subagent and CLI call using this argent install, and an unscoped call tears down THEIR devices too (a mid-recording devtools teardown degrades another agent's flow to brittle coordinate taps; that agent is warned, but its recorded steps are already the worse kind). Omit devices only when a machine-wide cleanup is what you actually want. Passing an EMPTY array scopes to nothing and stops nothing - it is not a way to ask for the machine-wide sweep. A JS-runtime debugger session is keyed by the id you called debugger-connect with. On a Metro serving two or more devices that id is not a udid or serial - connect refuses those and tells you to re-target with the logicalDeviceId it returns - so a scope built from list-devices ids cannot reach that session. Pass any such logicalDeviceId in devices ALONGSIDE the device id; { left_running } names the ones you missed. Returns { stopped } - the URNs of the services that were actually live and got shut down; an ERROR node is disposed too but never appears there, so an empty stopped only means nothing was still running. { unmatched } lists supplied ids that own no service here, so a mistyped id - or a device NAME passed where an id was expected - does not read as a clean machine. It is NOT proof the id is wrong: a Vega device is driven through CLI/adb shell-outs, so one you only booted and drove with the remote registers no service and always lands here — as does a real device of any platform this session never started anything on. Present ONLY when devices was supplied AND at least one id matched nothing - absent on an unscoped call and when every id matched. Stopping the same device twice does not report it unmatched: ownership counts regardless of service state. { left_running } lists live debugger sessions (and the network inspectors / React profiler sessions riding on them) whose id no device scope can name - re-call with that id to reap them. { aborted: true } means the caller cancelled the request part-way, so the rest of the machine was left untouched and neither of the other two fields was computed. Past the schema - which rejects an unknown key outright, so the udids slip is an error rather than a silent machine-wide sweep - the call always succeeds; reaping nothing is a result, not a failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
devicesNoDevice ids (iOS UDID / Android serial / Chromium id) to scope the teardown to — pass the devices THIS session actually used. Omit only for a deliberate machine-wide cleanup: one tool-server serves every agent using this argent install, so an unscoped stop also kills devices another agent is mid-session on.
Behavior5/5

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

No annotations are provided, so the description carries the full burden; it thoroughly discloses destructive scope (spawned processes, sockets, ports), cross-agent side effects (unscoped call tears down other agents' devices), and return-field semantics (stopped, unmatched, left_running, aborted). It even notes the call always succeeds and reaping nothing is a result, not failure.

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?

Though long, the description is dense and front-loaded with the action and scope; every sentence addresses a distinct concern (what is stopped, when to use, scoping pitfalls, return value interpretation). The length is justified by the tool's complexity and high-stakes destructive behavior.

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 there is no output schema, the description provides a full account of the return object and its edge cases. It also covers safety warnings and scoping restrictions, making it complete for an agent to select and invoke correctly.

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

Parameters5/5

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

The schema has one documented `devices` parameter, but the description adds substantial meaning: omit vs empty array distinction, logicalDeviceId alongside device id, duplicate handling, and unmatched semantics. This goes far beyond the schema's own description.

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 opens with 'Stop the services a device owns' and enumerates a specific list (simulator-server processes, native devtools, iOS accessibility service, TV-control daemons, Chromium CDP sessions, screen recordings, profilers, debugger sessions), clearly distinguishing it from a generic stop. It also differentiates device-scoped from machine-wide cleanup, separating it from the sibling stop-simulator-server.

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 instructs 'Call this when your session ends or the user says they are done.' It also tells when to omit devices ('only when a machine-wide cleanup is what you actually want') and warns against empty-array misuse. This is explicit when/when-not guidance.

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

Install Server

Other Tools

Latest Blog Posts

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/software-mansion/argent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server