web_session_close
Closes a session and stops billing browser time. Free. If you do not close it, it closes itself after a minute without use.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Closes a session and stops billing browser time. Free. If you do not close it, it closes itself after a minute without use.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well by disclosing that closing stops billing, that the call is free, and that abandonment triggers automatic closure after ~60s idle. It stops short of covering failure modes (invalid or already-closed sessionId) or what happens to session artifacts.
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 short sentences, zero filler, with the primary action and effect front-loaded before the billing and auto-close details. Every sentence earns its place.
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 lifecycle tool with no output schema and no annotations, the description supplies the key operational facts (billing stop, cost, auto-close). Only the parameter's origin/format is unaddressed, a minor gap given the obvious name.
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% and the description never mentions sessionId, so nothing clarifies where the identifier comes from or what form it takes. The self-descriptive parameter name is the only signal, which is thin compensation for a fully undocumented field.
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?
States a specific verb (closes) and resource (session) plus the operational effect (stops billing browser time). It is unambiguously distinct from siblings like web_session_open, web_scrape, or web_search_exa; an agent can pick it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent infers it should be called when finished with a session, since the description notes the session self-closes after a minute of inactivity. There is no explicit when-to-use, when-not-to-use, or named alternative, and no prerequisites are stated.
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.