Skip to main content
Glama
Silbercue

Public Browser

by Silbercue
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

download

Wait for a pending file to finish saving or list files already saved this session. Use status to block until complete, or list to poll history without waiting.

Instructions

Wait for pending downloads or list this session's downloaded files. Downloads start by themselves when you click a download link or open a file URL (PDF, CSV, …); this tool never triggers them. download() waits for a pending download to finish; download({ action: 'list' }) returns at once.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNostatus waits for pending downloads; list: history, never waits (use for polling)status
settleNoMs to wait for a download to START before reporting none — Chrome fires downloadWillBegin a few ms after the click; 0 = instant
timeoutNoMax wait in ms for pending downloads

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.10.5
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / action / description
      Previous value: -"status: check/wait for pending downloads (waits briefly for one to start, then until it finishes). list: full session history, returns immediately and never waits — use it for polling loops."New value: +"status waits for pending downloads; list: history, never waits (use for polling)"
    • changedInput schema / properties / settle / description
      Previous value: -"Grace window in ms to wait for a download to START before reporting 'no downloads' (default: 250). Chrome fires downloadWillBegin a few ms after the click that triggers it. Set 0 for an instant check, or use action: 'list' which never waits."New value: +"Ms to wait for a download to START before reporting none — Chrome fires downloadWillBegin a few ms after the click; 0 = instant"
    • changedInput schema / properties / timeout / description
      Previous value: -"Max wait time in ms for pending downloads (default: 30000)"New value: +"Max wait in ms for pending downloads"
  2. Changed2 schema fields changedv2.10.0
    • changedInput schema / properties / action / description
      Previous value: -"status: check/wait for pending downloads, list: show all session downloads"New value: +"status: check/wait for pending downloads (waits briefly for one to start, then until it finishes). list: full session history, returns immediately and never waits — use it for polling loops."
    • addedInput schema / properties / settle
      Added value: +{
+  "default": 250,
+  "description": "Grace window in ms to wait for a download to START before reporting 'no downloads' (default: 250). Chrome fires downloadWillBegin a few ms after the click that triggers it. Set 0 for an instant check, or use action: 'list' which never waits.",
+  "type": "number"
+}
  3. First observedv2.7.0

TDQS

A4.4/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. It clearly discloses that the tool never triggers downloads and that the default call waits while list returns immediately. It could additionally describe what happens when no download is pending or what the return payload looks like, but the schema partially covers timeouts and settling.

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?

Three sentences with no filler: the first states the core purpose, the second explains the triggering mechanism, and the third shows the behavioral difference between modes. The most important information is front-loaded.

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?

The tool has no output schema and no annotations, but the description plus the rich parameter schema gives the agent enough to call it correctly. It explains what the tool does, when to use it, and which mode to choose for waiting vs. listing, though an explicit note about the return format would make it fully 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%, with detailed descriptions for action, settle, and timeout, including defaults and enum meanings. The description adds a useful call-form example but not semantic information beyond what the schema already provides, so baseline 3 is appropriate.

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 states a specific verb and resource: 'Wait for pending downloads or list this session's downloaded files.' It also clearly distinguishes itself from triggering tools by saying 'this tool never triggers them,' which prevents confusion with click/navigate/file actions.

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?

It explicitly tells the agent when to use the tool: after a download link is clicked or a file URL is opened, and explains that downloads are triggered by user/browser actions, not by this tool. It also distinguishes the two modes: status waits, list returns immediately for polling.

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