@pipeworx/chrome-web-store

Connect: https://pipeworx.io/mcp — every tool in the catalog, including @pipeworx/chrome-web-store’s. Install: one-click buttons

No MCP client? Skip the connection: POST https://gateway.pipeworx.io/v1/tools/search_packs {"query":"..."} to find a tool below, GET /v1/tools/<name> for its schema, POST the same URL with arguments for the data — see For AI agents.

Tools: 3

Chrome Web Store listing data: one extension by id, free-text search, and extensions attributed to one publisher — name, rating, user count, version, last-updated date, category and website for each.

Tools

• chrome_web_store_extension(id) — full listing for one extension by its 32-character id: name, publisher, rating, rating count, user count, version, last-updated date, category, website, size, languages.
• chrome_web_store_search(query, limit?) — free-text search; matching extensions with id, name, rating, rating count, user count, category, website. A product-led-growth / adoption signal — what people are actually installing.
• chrome_web_store_by_publisher(publisher, max_checked?) — extensions attributed to one publisher name, confirmed against each candidate’s own listing. See “Known limits” below — this is bounded, not exhaustive.

Auth

Keyless. No login, no API key — this reads the same public pages a browser does.

Data sources

• Google, Chrome Web Store public listing and search pages. There is no public read API: Google’s own Chrome Web Store API only manages the caller’s OWN published items (OAuth, developer-scoped) and cannot look up someone else’s extension, so this pack reads the public pages the same way a browser would.

Known limits

• No public “list a developer’s extensions” page exists. _by_publisher runs the publisher name through the public search, then opens each candidate’s own listing and keeps only the ones whose rendered Developer disclosure actually names that publisher. That is an approximation of “all” bounded by what Chrome Web Store’s own search surfaces for that query — not a guaranteed-complete catalog of everything a publisher has shipped. It also makes one extra HTTP call per candidate checked (max_checked, default 10, max 25), so keep it modest.
• Not-found is a parse condition, not an HTTP status. An id with no live listing still answers HTTP 200 (Google redirects to a canonical empty-title slug with no matching data) — chrome_web_store_extension treats “no data item matches the requested id” as the not-found signal and returns found: false, never a silently-empty success.
• The slug in a detail URL is cosmetic. /detail/<anything>/<id> redirects to the real canonical slug server-side regardless of what precedes the id, so this pack never needs to know an extension’s display slug — only its id.
• Field extraction reads Google’s embedded page data, not a documented API, so a Chrome Web Store redesign could change the shape. The pack detects that defensively: it walks the page’s embedded JSON for an array whose first element is a 32-character extension id (Chrome’s own id alphabet, a-p only) rather than assuming a fixed block number, and it raises a loud upstream_parse error — naming the URL and body length — if a match is found but every field comes back empty, instead of returning an empty success.

Tools

• chrome_web_store_extension — Chrome Web Store listing for ONE extension by its 32-character id: name, publisher, rating, rating count, user count, version, last-updated date, category, website. Public listing data, no login.
• chrome_web_store_search — Free-text search of the Chrome Web Store: matching extensions with id, name, rating, rating count, user count, category, website. PLG/adoption signal — what tools people are actually installing.
• chrome_web_store_by_publisher — Extensions on the Chrome Web Store attributed to one publisher/developer name, confirmed against each listing’s own developer disclosure. Bounded by Chrome Web Store’s own search — there is no public