Skip to main content
Glama
deenesjakoruzh
dowant

LionScraper

by dowant
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

ping

:

Instructions

Purpose

Verify the LionScraper extension is connected over the local WebSocket bridge. If disconnected, tries Chrome first, then Edge (each installed channel): detect paths and whether the process is running. For each channel, the Server waits up to postLaunchWaitMs for the extension to register: if the browser was not running and autoLaunchBrowser allows it, the Server starts it; if the browser was already running, it polls without closing that browser. If this ping started the browser and registration still does not occur within postLaunchWaitMs, the Server closes only that launched instance before trying the next channel. Worst-case wait is up to about 2× postLaunchWaitMs when both channels each use a full wait (e.g. two launches, two already-running browsers, or a mix).

When to call

  1. In a new session, before any scrape* tool.

  2. Right after any tool returns EXTENSION_NOT_CONNECTED.

Returns

  • Success: ok, bridgeOk, browser, development (always node for this npm package), extensionVersion; optional diagnostics when the server assisted (launched true or false, waitedMs, selectedBrowser).

  • Failure: BROWSER_NOT_INSTALLED (no Chrome/Edge found on standard paths), or EXTENSION_NOT_CONNECTED with details.browserProbe / details.bridge / details.install.

Parameters

  • autoLaunchBrowser: optional boolean. If false, never spawn a browser; non-running candidates are skipped and the Server continues to the next installed channel when possible. If omitted: default true (server may auto-launch eligible browsers).

  • postLaunchWaitMs: optional; max time (ms) to poll for WebSocket registration after spawning a browser or when a browser is already running, clamped 3000–60000, default 20000.

Notes

Does not load pages or extract data. Portable browser installs may not be detected. Optional lang follows the lang section above.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoBCP 47 for human-readable errors this call: en-US | zh-CN. Omitted → English. Pass zh-CN when the user works in Chinese; the Server cannot infer chat language.
autoLaunchBrowserNoIf true, when the bridge is down the Server may start Chrome then Edge (each installed channel) if not running. If false, never spawn; skips non-running channels and tries the next. Omitted: defaults to true.
postLaunchWaitMsNoMilliseconds to poll for the extension WebSocket register after spawning a browser or while Chrome/Edge is already running (clamped 3000–60000; default 20000).

Tool Definition Quality

A4.8/5.0
Behavior5/5

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

No annotations provided, but description comprehensively covers: side effects (browser launching/closing), polling logic, timeout calculations (2× multiplier), cleanup behavior (closes only launched instances), success/failure return structures, and specific error codes (BROWSER_NOT_INSTALLED, EXTENSION_NOT_CONNECTED sub-fields).

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?

Uses markdown headers (Purpose, When to call, Returns, Parameters, Notes) for scanability. Length is substantial but appropriate for complexity (browser orchestration without output schema). Key constraints (3000-60000 clamp) appear in both schema and description.

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?

No output schema exists, but description compensates with detailed Returns section documenting success fields (ok, bridgeOk, browser, diagnostics) and failure modes. Notes section covers limitations (portable browsers). Complete for a complex connectivity/orchestration tool.

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

Parameters4/5

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

Schema has 100% coverage (baseline 3). Description adds value by explaining parameter interactions: how autoLaunchBrowser affects channel skipping logic, and how postLaunchWaitMs creates worst-case 2× wait scenarios when polling already-running browsers.

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?

Opens with specific verb+resource: 'Verify the LionScraper extension is connected over the local WebSocket bridge.' Explicitly distinguishes from scrape* siblings via 'When to call' section referencing them and Notes stating 'Does not load pages or extract data.'

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?

Contains explicit 'When to call' section listing two precise scenarios: (1) before any scrape* tool in new sessions, and (2) after EXTENSION_NOT_CONNECTED errors. Provides clear temporal ordering relative to sibling tools.

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/dowant/lionscraper-mcp'

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