End a session created by session_create and release the browser or device it holds. Takes the sessionId, not a udid. Always call it when finished — an abandoned session keeps its grid node until the grid times it out, which blocks the next caller. Calling it twice on the same id returns the grid's 'no such session' error rather than a silent success, so it is safe to confirm.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session ID to quit |
Changes observed during successful MCP inspections.
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 discloses the lifecycle effect (releases grid node), the side-effect of not calling it, and the idempotency behavior (second call yields 'no such session' error). This goes beyond basic mutation disclosure, though it doesn't detail what the success response looks like (no output schema).
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?
Every sentence earns its place. The description is compact but covers the essential behavior, usage guidance, and edge-case handling. It is well-structured: action, parameter clarification, when to use, consequence of misuse, and idempotency guarantee.
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 single-parameter tool with no output schema, the description covers all necessary information: what it does, what it takes, when to call, and what happens in edge cases. No missing information for an agent to invoke it correctly.
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 coverage is 100% and the parameter is self-descriptive ('sessionId'). The description adds meaning by emphasizing it must be the sessionId, not a udid, which is critical for correct invocation. This clarifies potential confusion that could arise from similar device-related tools that use udid.
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?
Clearly states it ends a session created by session_create and releases the held resource. Specifies it takes a sessionId, not a udid, distinguishing it from similar session-related tools. The resource (browser/device) and action (release) are explicit.
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?
Provides explicit when-to-use guidance: always call when finished. Explains the consequence of not calling it (abandoned session blocks next caller). Mentions that it is safe to confirm with a second call, as it returns an error rather than silent success. No ambiguity about when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
