What did Hlido score Feedthrough?

Feedthrough scored 78/100 (STEADY) in Hlido's independent, hands-on review.

How much does Feedthrough cost?

Hlido recorded the pricing model as: Paid. Derived from evidence Hlido holds, not vendor-supplied; verify current prices on the vendor's pricing page.

Does any vendor pay Hlido for placement?

No. Hlido takes no money from the agents it rates — scoring weights stay private and the evidence behind every verdict is public.

Feedthrough

Name: Feedthrough review
Item: Feedthrough
Rating: 78
Author: Hlido Editor

Coding · tested 2026-08-14 · by the Hlido desk, not the vendor

In short: The rare MCP debugging tool that names its own architectural trade-off and argues it — an in-page bridge instead of external CDP control, with the reasoning published rather than implied.

Visit Feedthrough → scorecard.json

Quick answer

Feedthrough scores 78/100 (STEADY) on Hlido’s independent, hands-on test (reviewed 2026-08-14). STEADY because the public surface does the hard part well — a specific, defensible technical position, a concrete architecture, a named tool count, a real install path and named client support. Pricing: Paid.

Hlido Editor · 2026-08-14

Feedthrough injects a lightweight bridge into a running page and exposes DOM state, console logs and network traffic as 16 MCP tools, so an agent can inspect and drive the app from the inside. The landing page is unusually good at the thing most tools in this category skip: it states the competing approach (Puppeteer/CDP external control), says plainly that it chose differently, and explains why — the bridge rides inside the existing execution environment rather than attaching a separate automation channel. The extended metaphor about vacuum-chamber feedthroughs is indulgent, but it earns its place by making the design decision legible to someone deciding between this and a browser-driver tool. The architecture is drawn out concretely: @feedthrough/core in the browser doing console and fetch/XHR interception plus DOM inspection, @feedthrough/mcp locally running 16 tools over stdio, a WebSocket on 8765 between them, and named client support for Claude Code and Cursor. Install is a single npm command. What is missing is the operational half — nothing describes what happens if the WebSocket port is already bound, what the bridge does in a production build, or what data crosses the socket. 'Zero changes to your production build' is claimed but not demonstrated. For a debugging tool that reads console logs and network requests, a short data-handling note would close the last real gap.

Why STEADY

STEADY because the public surface does the hard part well — a specific, defensible technical position, a concrete architecture, a named tool count, a real install path and named client support. Held below the top band because the operational and data-handling story is absent (what crosses the socket, what happens in production builds, port-conflict behaviour) and because the demo is presented as scripted scenarios rather than something a visitor can run.

What we saw

4 screenshots captured by the Hlido engine during the reviewed run (run-498872e0c4c65152-feedthrough-dev). Our own captures — not vendor marketing material.

Feedthrough — run screenshot 1 (home.png) — home.png

Feedthrough — run screenshot 2 (page_.png) — page_.png

Feedthrough — run screenshot 3 (page__demo.png) — page__demo.png

Feedthrough — run screenshot 4 (page__how-it-works.png) — page__how-it-works.png

What it does well

States its architectural trade-off explicitly and argues it, instead of leaving the reader to infer it
Concrete architecture: named packages, named transport, a specific port, and the responsibility split drawn out
Tool count published (16) rather than gestured at
Single-command install, copy-pasteable from the fold
Named client support (Claude Code, Cursor) and a framework section

What it fails at

'Zero changes to your production build' is asserted without demonstration or explanation
No statement on what data crosses the WebSocket, or whether console/network capture is filtered
Demo is a set of scripted bug scenarios, not something a visitor can execute
No guidance on port conflicts, multiple-tab behaviour, or what happens when the bridge is left in a build
No versioning, changelog or maintenance-cadence signal on the public surface

Red flags

The bridge intercepts console output and fetch/XHR traffic, which in a real application can include tokens and personal data — and no public statement describes what is captured, retained or transmitted.
'Zero changes to your production build' is a strong safety claim about a tool that injects code into a running page; it deserves evidence and currently has none.

Best for

Developers debugging web apps from inside an AI coding client rather than switching to browser devtools
Teams whose bugs are state-dependent and hard to reproduce through external browser automation
Anyone who has hit the limits of CDP-based tools on apps with complex client-side state

Not recommended for

Production or customer-facing environments — this is a development-time tool and the data posture is undocumented
Teams needing a documented security review before injecting a bridge that reads console and network traffic
Non-JavaScript application stacks; the whole design assumes a browser runtime

Pricing & access

ModelPaid

Derived from Hlido-held evidence only (engine checklist + editorial text); quotes are verbatim from the scorecard; not vendor-supplied; re-derived daily. Verify current prices on the vendor's pricing page. Last verified 2026-08-11.

Compared to

Microsoft Playwright MCP external-automation-vs-internal-inspection
Playwright MCP drives a browser from outside via CDP and is the mature default for automation. Feedthrough deliberately inverts that to reach in-page state a driver cannot see. Choose Playwright MCP for automation and testing, Feedthrough for debugging live application state.
Browser Use task-execution-vs-debugging
browser-use is oriented at task completion by an agent in a browser; Feedthrough is oriented at a developer diagnosing their own app. Different jobs despite the surface similarity.

Agent relevance

MCP SDK Behavioral-testable

Agentic-Commerce Readiness 52/100 · INTEGRABLE

Independent readiness for agent delegation & transaction. How it’s scored · check live

Purpose-built as an MCP server with 16 published tools and a documented stdio transport, plus an installable browser-side package. The tool count and responsibility split are public, so an agent can reason about capability before connecting.

Agent-friendly score: 8/10

Evidence

Homepage publicly accessible and value proposition clearly stated — source (2026-08-14) verified
Pricing page discoverable in 2 clicks from homepage — source (2026-08-14)
Documentation or live demo accessible without login — source (2026-08-14) verified
Integration list or supported frameworks documented — source (2026-08-14) verified
Authentication / data handling claims publicly stated — source (2026-08-14)

scorecard.json · transparency passport · registry · methodology

More: compare agents · best of · developer tools · incident registry

Verdict by Hlido Editor, our automated editorial system · Method: public-surface-tier-2+editorial-narrative-v2 · Methodology version 2026.08 ·

How this page was produced. The scores, claim verdicts and evidence come from automated hands-on testing of the product’s public surface. The written analysis is drafted by an AI system, and pages publish without a person reviewing each one. Hlido publishes this record and answers for it — tell us if anything here is wrong and we will correct it.

Embed this trust badge

Live, always-current independent score — free to embed on your site or README. No vendor pays for placement.

Markdown

[![Hlido trust score](https://hlido.eu/badge/feedthrough-feedthrough.svg)](https://hlido.eu/check/?agent=feedthrough-feedthrough)

HTML

<a href="https://hlido.eu/check/?agent=feedthrough-feedthrough"><img src="https://hlido.eu/badge/feedthrough-feedthrough.svg" alt="Hlido trust score"></a>