What can you do with this server?

Feedthrough is a browser debugging tool that lets AI agents inspect and interact with a live web page via MCP tools. Session & Connection Management * get_instructions() — Get a usage guide with recommended workflow and selector tips * connection_status() — Check if a browser is connected and list open tabs (id, URL, active status) * get_page_info() — Retrieve current URL, title, readyState, viewport size, scroll position, and user agent Console & Network Inspection * get_console_logs() — Capture console output, uncaught exceptions, and unhandled promise rejections; filter by level, content, or timestamp * get_network_requests() — View all fetch/XHR requests including URL, method, status, duration, headers, and bodies (up to 10 KB); filter by URL or method DOM Inspection * query_dom(selector) — Find elements matching a CSS selector and get a summary (tag, id, classes, text content) * inspect_element(selector) — Deep-dive into a single element: bounding rect, computed styles, visibility, occlusion, accessibility info, overflow, pseudo-element content, and form state * get_html(selector) — Retrieve the raw outerHTML of an element (up to 50 KB) Page Interaction * click(selector) — Simulate a user click on an element * fill(selector, value) — Set the value of an input, textarea, or select, firing appropriate events (works with React/Vue controlled inputs) * hover(selector) — Trigger mouseover/mouseenter events to reveal tooltips or dropdowns * press_key(selector, key) — Dispatch keyboard events (Enter, Escape, Tab, arrow keys, or characters) Live DOM Previewing * set_style(selector, properties) — Apply inline CSS changes live to preview visual fixes * set_attribute(selector, name, value) — Set or remove element attributes live (e.g., toggle disabled, swap classes) * set_text(selector, text) — Replace an element's text content to preview wording changes * reset_overrides() — Undo all set_style, set_attribute, and set_text changes and restore original values All commands automatically route to the most recently active browser tab.

Which integrations are available for this server?

Automatically injects the debug bridge into each Cypress test page, enabling AI agents to inspect DOM, console logs, network requests, and interact with the page during test runs. Wraps Next.js configuration to inject the debug bridge in dev mode, allowing AI agents to observe and control Next.js applications. Registers as a Nuxt module to inject the debug bridge into Nuxt 3 apps in dev mode, providing AI agents with real-time debugging capabilities. Injects the bridge via a Vite dev server middleware into Remix applications, enabling AI agents to debug Remix apps. Plug into Vite to inject the bridge into static HTML pages, allowing AI agents to debug Vite-based applications (React, Vue, Solid, Preact). Adds the bridge as a global entry point in Webpack configurations, enabling AI agents to debug Webpack-based applications.

Feedthrough

Official

by feedthrough

Overview Schema Related Servers Score Discussions

TypeScript

Local

Feedthrough is a browser debugging tool that lets AI agents inspect and interact with a live web page via MCP tools.

Session & Connection Management

get_instructions() — Get a usage guide with recommended workflow and selector tips
connection_status() — Check if a browser is connected and list open tabs (id, URL, active status)
get_page_info() — Retrieve current URL, title, readyState, viewport size, scroll position, and user agent

Console & Network Inspection

get_console_logs() — Capture console output, uncaught exceptions, and unhandled promise rejections; filter by level, content, or timestamp
get_network_requests() — View all fetch/XHR requests including URL, method, status, duration, headers, and bodies (up to 10 KB); filter by URL or method

DOM Inspection

query_dom(selector) — Find elements matching a CSS selector and get a summary (tag, id, classes, text content)
inspect_element(selector) — Deep-dive into a single element: bounding rect, computed styles, visibility, occlusion, accessibility info, overflow, pseudo-element content, and form state
get_html(selector) — Retrieve the raw outerHTML of an element (up to 50 KB)

Page Interaction

click(selector) — Simulate a user click on an element
fill(selector, value) — Set the value of an input, textarea, or select, firing appropriate events (works with React/Vue controlled inputs)
hover(selector) — Trigger mouseover/mouseenter events to reveal tooltips or dropdowns
press_key(selector, key) — Dispatch keyboard events (Enter, Escape, Tab, arrow keys, or characters)

Live DOM Previewing

set_style(selector, properties) — Apply inline CSS changes live to preview visual fixes
set_attribute(selector, name, value) — Set or remove element attributes live (e.g., toggle disabled, swap classes)
set_text(selector, text) — Replace an element's text content to preview wording changes
reset_overrides() — Undo all set_style, set_attribute, and set_text changes and restore original values

All commands automatically route to the most recently active browser tab.

Feedthrough

Debug with AI — from inside your app.

Feedthrough injects a lightweight debug bridge into any running web page, then exposes everything — DOM state, console logs, network requests, and user interactions — as MCP tools. Any MCP-compatible AI agent can inspect and drive the page conversationally, in real time.

Browser (any)
 └── @feedthrough/core          ← injected into your page
      ├── console interceptor
      ├── fetch / XHR interceptor
      └── DOM inspector
      ↕  WebSocket
@feedthrough/mcp               ← MCP server, exposes tools over stdio
 └── Tools: click, fill, inspect_element, query_dom,
            get_console_logs, get_network_requests, …
      ↕  MCP protocol
Claude Code / Cursor / any MCP client

The name

Many physics and chemistry experiments run inside a sealed vacuum chamber, with all the air pumped out so nothing contaminates the experiment. The catch: you still need to control instruments inside the chamber and read their measurements, and the smallest air leak ruins the run. A feedthrough is the part that solves this — a specially engineered connector that carries electrical signals through the chamber wall while keeping the vacuum perfectly intact. You can't reach inside, but the feedthrough lets you observe and control what's happening in there anyway.

The parallel is exact: Feedthrough extracts runtime debug data from inside a running web app without disturbing it, and sends control signals back in — clicks, keystrokes, DOM queries — without breaking the execution environment.

Related MCP server: Curupira

Why Feedthrough?

Every other browser MCP tool is an external observer — it controls the browser from outside via Puppeteer or CDP and only works in Chrome. Feedthrough is an embedded agent. It runs inside the page, so it sees:

Framework internals (React component trees, Redux store, custom globals)
Any browser, not just Chrome
Your existing dev workflow — no separate controlled browser to launch
Cypress's own browser context during test runs

Packages

Package	Description
`@feedthrough/core`	In-browser bridge — intercepts console, fetch, XHR; handles commands
`@feedthrough/mcp`	MCP server — bridges any MCP client to the browser via WebSocket
`@feedthrough/cypress`	Cypress adapter — auto-injects the bridge before each test page load
`@feedthrough/playwright`	Playwright adapter — injects the bridge via `page.addInitScript()`
`@feedthrough/vite`	Vite plugin for apps with a static `index.html`
`@feedthrough/webpack`	Webpack plugin — adds bridge as a global entry point
`@feedthrough/nextjs`	Next.js adapter — wraps `next.config.ts` with `withFeedthrough()`
`@feedthrough/nuxt`	Nuxt 3 module
`@feedthrough/sveltekit`	SvelteKit adapter — injects via the `handle` hook
`@feedthrough/remix`	Remix adapter — injects via a Vite dev server middleware

Framework support

Framework	Adapter	Notes
Vite + React / Vue / Solid / Preact	`@feedthrough/vite`	Static `index.html` — plugin uses `transformIndexHtml`
Next.js	`@feedthrough/nextjs`	Wraps the webpack config; dev only
Nuxt 3	`@feedthrough/nuxt`	Registers as a Nuxt module; dev only
SvelteKit	`@feedthrough/sveltekit`	`handle` hook with `transformPageChunk`; dev only
Remix	`@feedthrough/remix`	Vite dev server middleware; dev only
Webpack apps	`@feedthrough/webpack`	Global entry point; guards against production mode
Cypress	`@feedthrough/cypress`	`window:before:load` hook
Playwright	`@feedthrough/playwright`	`page.addInitScript()`

Quick start

1. Start the MCP server

npx @feedthrough/mcp

The server listens for browser connections on ws://127.0.0.1:8765 and exposes MCP tools on stdio. Override the port with FEEDTHROUGH_PORT=9000.

2. Add it to your MCP client config

{
  "mcpServers": {
    "feedthrough": {
      "command": "npx",
      "args": ["@feedthrough/mcp"]
    }
  }
}

3. Inject the bridge into your page

Vite + React / Vue / Solid / Preact:

// vite.config.ts
import { feedthrough } from "@feedthrough/vite";
export default defineConfig({ plugins: [feedthrough()] });

Next.js:

// next.config.ts
import { withFeedthrough } from "@feedthrough/nextjs";
export default withFeedthrough()({ /* your next config */ });

Nuxt 3:

// nuxt.config.ts
export default defineNuxtConfig({ modules: ["@feedthrough/nuxt"] });

SvelteKit:

// src/hooks.server.ts
import { feedthroughHandle } from "@feedthrough/sveltekit";
import { sequence } from "@sveltejs/kit/hooks";
export const handle = sequence(feedthroughHandle);

Remix:

// vite.config.ts
import { feedthrough } from "@feedthrough/remix";
export default defineConfig({ plugins: [remix(), feedthrough()] });

Webpack:

// webpack.config.mjs
import { FeedthroughPlugin } from "@feedthrough/webpack";
export default { plugins: [new FeedthroughPlugin()] };

Cypress:

// cypress/support/e2e.ts
import { setupFeedthrough } from "@feedthrough/cypress";
setupFeedthrough();

Playwright:

// import test from the adapter instead of @playwright/test
import { test, expect } from "@feedthrough/playwright";

Or manually (any bundler):

// main.ts
if (import.meta.env.DEV) {
  import("@feedthrough/core").then(({ init }) => init());
}

4. Open your page and start asking

Once the bridge connects you'll see [feedthrough] tab connected in the MCP server output. For the simplest experience, keep a single tab open. Multiple tabs can connect at the same time and commands are routed to the most recently active one, but a single tab avoids any ambiguity.

Then ask your AI agent:

> What's on the page right now?
> Click the submit button and tell me what network requests fired
> Why is the counter showing the wrong value?

MCP tools

Tool	Description
`get_instructions()`	Usage guide — recommended workflow, tool ordering, and selector tips
`query_dom(selector)`	All elements matching a CSS selector
`inspect_element(selector, properties?)`	Tag, attributes, full bounding rect + inViewport, ancestor `path`, curated computed styles, overflow info (clipped/overflowing content), `clipped`-by-ancestor info, effective visibility (`visible` + `hiddenReason`, accounting for ancestors), occlusion (`hittable` + `occludedBy`), accessibility (`a11y`: role, name, states), `pseudo` ::before/::after content, live form state; `properties` reads extra CSS props by name
`get_html(selector)`	Raw outerHTML of a region (capped at 50 KB)
`get_console_logs(limit?, levels?, match?, since?)`	Console output (all methods) plus uncaught errors & promise rejections; filter by `levels`, `match`, or `since` timestamp
`get_network_requests(filter?, since?)`	Captured fetch + XHR — URL, method, status, duration, headers, request/response bodies (10 KB cap); narrow by `filter` or `since`
`get_page_info()`	URL, title, readyState, viewport size, scroll position, user agent
`connection_status()`	List connected tabs and which one is currently active
`click(selector)`	Click an element via native `click()` (fires click + default activation, not the pointer sequence)
`fill(selector, value)`	Set an input/textarea/select value (fires input + change, not keystrokes)
`hover(selector)`	Fire mouseover/mouseenter to mount hover UI (JS handlers, not CSS `:hover`)
`press_key(selector, key)`	Dispatch a key press — Enter, Escape, Tab, arrow keys, or a character
`set_style(selector, properties)`	Preview a visual fix — set inline CSS live (not saved to source)
`set_attribute(selector, name, value)`	Preview an attribute change — toggle disabled, swap a class, set aria-* (`null` removes)
`set_text(selector, text)`	Preview wording/label changes — replace an element's text
`reset_overrides()`	Undo every live `set_style` / `set_attribute` / `set_text` change

Live edit is a preview, not a save. set_style / set_attribute / set_text mutate the running DOM so the agent can show you a fix without a rebuild. They are not written to your source and reset on reload/HMR. The loop: the agent previews live, you confirm, then it edits the actual source to make it stick. Changes a framework owns (text, controlled attributes) may be overwritten on the next render — the tool result flags this so the agent can tell you.

Example app

examples/react-app is a small React app with three deliberate bugs — a good sandbox for trying out the diagnostic workflow:

# Terminal 1 — app
cd examples/react-app && pnpm dev    # http://localhost:5173

# Terminal 2 — MCP server
cd packages/mcp && node dist/index.js

Connect an AI agent and ask it to find what's wrong. The three bugs are all invisible from the UI but findable in under a minute via get_console_logs, get_network_requests, and query_dom.

Using with an AI agent

Recommended workflow

connection_status() — confirm the bridge is connected before anything else
get_console_logs() — errors and app output often identify the root cause immediately
get_network_requests() — look for failed fetches, wrong URLs, or missing calls
query_dom(selector) — find elements and check what's rendered
inspect_element(selector) — deep-dive on a specific element
click() / fill() — interact, then re-check logs and network

Project-memory snippet

Add this to whatever project-memory file your AI agent reads — CLAUDE.md for Claude Code, .cursor/rules/*.md for Cursor, and so on — to prime it with the right workflow:

## Debugging with Feedthrough

A Feedthrough MCP server is configured. When investigating UI bugs:

1. Call `connection_status()` first — fail fast if no browser is connected.
2. Check `get_console_logs()` before touching the DOM.
3. Check `get_network_requests()` for failed or missing API calls.
4. Use `query_dom` to orient yourself, `inspect_element` to dig into a specific element.
5. Interact with `click` / `fill`, then re-check logs.

Prefer element IDs as selectors — they're stable. Avoid long attribute selectors.

Sample system prompt

For one-off sessions with any MCP client:

You have access to the Feedthrough MCP server. It gives you live access to a running web app
from inside the browser — console logs, network requests, DOM state, and the ability to click
and fill inputs. Start by calling get_instructions() for the recommended workflow.

Security

v1 is local-only. Two guards enforce this:

Localhost binding — the WebSocket server binds to 127.0.0.1, so it is not reachable from other machines on the network.
Origin validation — each incoming WebSocket connection is checked against its Origin header. Loopback origins (localhost, 127.0.0.1, ::1) are always accepted, as is any host ending with an allowed suffix (default .test, so local dev domains like Laravel Valet's myapp.test connect out of the box). Override the suffix list with FEEDTHROUGH_ALLOWED_HOST_SUFFIXES (comma-separated; replaces the default — set it empty for loopback-only). Any other origin is rejected. A .test origin can only be presented by a page actually served from a .test host, which resolves locally, so this widens which local origins connect, not network reach.

What gets captured

Captured network requests include request and response bodies and headers, including Authorization, Cookie, and any other headers your app sends. That's intentional — debugging auth and session flows needs them. But the data does leave the page over the local WebSocket, flows through the MCP server, and reaches whichever AI agent you've connected. If that agent is cloud-backed, sensitive values reach the provider. Run Feedthrough only on dev machines and dev data. Do not inject @feedthrough/core into production builds.

Development

pnpm install       # install all workspace deps
pnpm build         # build all packages
pnpm typecheck     # typecheck all packages

Requires Node.js ≥ 22 and pnpm.

Releasing

Packages are versioned independently — bump only the package(s) you actually changed and leave the rest alone. Publishing to npm is handled by CI: the Publish to npm workflow runs on every published GitHub Release and publishes only the packages whose name@version isn't on npm yet, skipping the ones already published (via OIDC trusted publishing, no tokens).

To cut a release:

# 1. Bump the changed package(s) only
pnpm --filter @feedthrough/mcp exec npm version 0.1.1 --no-git-tag-version
# When bumping @feedthrough/mcp, also bump the version (and packages[].version) in
# packages/mcp/server.json to match — the MCP registry validates them against npm.
git add packages/mcp/package.json packages/mcp/server.json
git commit -m "Release @feedthrough/mcp 0.1.1"
git push

# 2. Create a GitHub Release (this triggers the publish workflow)
gh release create v0.1.1 --title "v0.1.1" --notes "..."

The workflow builds all packages and publishes only the newly bumped ones. It also publishes @feedthrough/mcp to the official MCP registry (io.github.feedthrough/feedthrough) via GitHub OIDC whenever the registry is missing the current version, so a failed registry publish can be retried by re-running the workflow (Actions tab, "Run workflow") with no version bump. Mark a release as a pre-release to skip publishing.

License

MIT — see LICENSE.

Available Tools

16 tools

clickA

Click an element by calling its native click(), which fires a click event and runs the default activation: following a link, toggling a checkbox or radio, submitting a form. Prefer an id selector (#submit-btn) for reliable targeting. Note it does NOT synthesize the preceding pointer/mouse sequence (pointerdown / mousedown / mouseup) or move focus, so a handler wired specifically to those events rather than to click won't fire; for keyboard-driven activation use press_key instead. Behavior: if the selector matches nothing the call returns an error; it does not scroll the element into view, and it does not wait for any resulting navigation, network, or re-render to settle, returning as soon as the click is dispatched. Observe the effect with a follow-up get_console_logs / get_network_requests / query_dom. Returns the tag and id of the clicked element.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector for the element to click, e.g. '#submit-btn' or 'button[type=submit]'. If several match, the first in document order is clicked.

TDQS

A4.9/5.0

Behavior5/5

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

Despite no annotations, the description fully discloses behavior: fires native click, no synthesized mouse events, no focus change, no scroll, no waiting for navigation/network/re-render, returns immediately, returns tag and id, error on no match.

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?

Long but each sentence earns its place. Front-loaded with purpose. Minor redundancy but well-structured overall.

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?

For a one-parameter tool with no output schema, the description is thorough: purpose, parameter guidance, behavioral nuances, error cases, return value, and follow-up suggestions.

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

Parameters5/5

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

The sole parameter 'selector' is fully covered. Description adds value beyond schema: prefers id selector, explains multiple-match behavior, and gives examples.

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 clearly states it clicks an element by calling native click(), explaining the event and default activation. It distinguishes from siblings like press_key for keyboard activation.

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?

Provides explicit guidance: use for clicking, prefer id selector, avoid when relying on pointer/mouse events, and for keyboard-driven use press_key. Also notes limitations (no scrolling, no waiting) that inform usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

connection_statusA

Check whether a browser with the Feedthrough bridge is currently connected. Returns connected flag and a list of open tabs (id, url, which is active). Call this first — every tool except get_instructions requires a connected browser.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations are provided, but the description fully discloses the tool's behavior: it checks connectivity and returns status and tabs. No side effects are mentioned, which is appropriate for a read-only check.

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?

Two sentences with no wasted words. Front-loaded with the key action, and additional detail provided efficiently.

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?

Given no parameters and no output schema, the description fully describes what the tool does and what it returns, plus crucial usage context. No gaps.

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?

The tool has zero parameters, so the schema covers 100%. The description adds meaning by explaining the tool's function and output, fulfilling the baseline expectation.

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 clearly states the tool checks browser connectivity and returns a connected flag plus open tabs. It uses specific verbs and explains the return value, leaving no ambiguity.

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?

Explicitly advises to call this first because every tool except get_instructions requires a connected browser, providing excellent when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fillA

Set the value of an input, textarea, or select element. Focuses the element, assigns the value through the element's native value setter (so React/Vue controlled inputs register the change), then fires bubbling input and change events. The value is set in one shot, not typed character by character, so per-keystroke handlers (keydown / keypress / keyup / beforeinput) do NOT fire; to send Enter to submit or trigger a key shortcut, follow with press_key. Prefer an id selector (#search-input). If the selector matches nothing the call returns an error; it returns as soon as the events are dispatched and does not wait for downstream validation or re-renders. Returns the tag and the value that was set.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector for the input, textarea, or select to fill, e.g. '#email' or 'input[name=q]'.
`value`	Yes	The full value to set. It replaces the field's current contents (it is not appended); for a <select>, pass the target option's value attribute.

TDQS

A4.7/5.0

Behavior5/5

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

The description fully discloses behavioral traits: focusing, native value setter, fired events, non-firing events, error on no match, no waiting. No annotations are needed as the description carries the full burden.

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?

The description is efficiently structured, starting with the main purpose and then detailing behavior. Every sentence adds unique value without repetition.

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?

For a tool with no output schema and low complexity, the description is complete: it covers purpose, behavior, edge cases, and return information. No gaps.

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 coverage is 100%, and the description adds meaning: value replaces contents, and for select, pass target option's value. This goes beyond the schema's basic descriptions.

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 explicitly states the tool fills input, textarea, or select elements, with a specific verb and resource. It clearly distinguishes from sibling tools like click or press_key.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises preferring id selectors and mentions using press_key for keyboard actions. It provides clear context but could explicitly state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_console_logsA

Return console output captured since the bridge connected. Covers every console method — log/warn/error/info/debug plus dir, table, assert, trace, count, countReset, time/timeEnd/timeLog, group/groupCollapsed/groupEnd, and clear. Each entry has a 'level' (the closest of the five standard levels); rich methods also carry a 'method' field, and console.trace() plus failing console.assert() entries include a 'stack'. Uncaught exceptions and unhandled promise rejections are also captured (level 'error', method 'uncaught' / 'unhandledrejection') even though the app never logged them. When the app is noisy with framework or deprecation warnings, pass levels: ['error'] (or ['error', 'warn']) so the real errors aren't buried, and use 'match' to narrow by content. Pass 'since' (a ms timestamp from an earlier entry's 'ts', or Date.now() before an action) to see only what happened after that point. Read-only: it returns a passively captured buffer and neither clears the console nor changes the page. Always check this early — app errors and debug output often identify the root cause immediately.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Cap the result to the N most-recent entries, e.g. 50. Omit to return everything captured since the bridge connected.
`levels`	No	Restrict to these levels, e.g. ['error'] to skip noisy warn/info/debug, or ['error', 'warn'] for both. Omit for all levels.
`match`	No	Case-insensitive substring filter on the serialized message content
`since`	No	Only entries with ts >= this (ms epoch). Scope to 'what happened after I did X'.

TDQS

A4.6/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. Explicitly states it is 'Read-only', returns passively captured buffer, does not clear console or change page. Details what types of entries are captured, including uncaught exceptions and unhandled rejections. Fully transparent.

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?

Single paragraph packed with info but not overly verbose. Each sentence adds value. Could benefit from slight structuring (e.g., bullet points for filters), but still efficient and front-loaded with core purpose.

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, but description explains return structure (level, method, stack). Covers edge cases like uncaught exceptions. For a read-only log retrieval tool with 4 optional params, no gaps identified.

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 coverage is 100%, baseline 3. Description adds significant value: explains levels filtering with examples, match as case-insensitive substring, since as ms timestamp from earlier entry, and limit as capping most recent. Enhances understanding beyond schema descriptions.

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?

Description uses specific verb 'Return' and resource 'console output captured since the bridge connected'. It details coverage of console methods and extra fields, clearly distinguishing from sibling tools like get_network_requests or get_page_info which deal with other aspects of page state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use levels filter to reduce noise, match for content narrowing, and since for time-scoping. Also advises 'Always check this early' as a usage strategy. Lacks explicit when-not-to-use but offers strong contextual direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_htmlA

Return the outerHTML of an element (capped at 50 KB). Use this when the summarised query_dom output isn't enough and you need to see the actual markup/structure of a region. Read-only: it only reads the DOM and makes no changes, and it returns an error if the selector matches nothing.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector for the region to dump, e.g. '#app' or '.modal'. If several match, the first in document order is used. Scope it tightly: the outerHTML is capped at 50 KB.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, description fully carries burden. It discloses read-only nature, 50 KB cap, and error on no match. This is comprehensive behavioral info.

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?

Two sentences, front-loaded, no wasted words. Every sentence adds value.

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?

Given no output schema, description doesn't detail return format but outerHTML is standard. Capping is mentioned. Sufficient for a simple tool.

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 coverage is 100%, so baseline is 3. Description adds a hint to scope tightly due to cap, which adds value but not a lot of new semantics.

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?

Description clearly states it returns the outerHTML of an element, with a usage hint distinguishing it from query_dom. The verb 'return' and resource 'outerHTML of an element' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use when query_dom output is insufficient and you need actual markup. Mentions read-only and error conditions. Lacks explicit when-not-to-use but the alternative is named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_instructionsA

Returns the Feedthrough usage guide as a Markdown text document, with sections for the recommended workflow, tool-ordering tips, and selector advice. Read-only and takes no arguments; it does not touch the page or require a connected browser. Call it at the start of a debugging session if you are unfamiliar with Feedthrough or want a quick refresher.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 fully covers behavioral traits: read-only, no arguments, no page or browser connection required. Sufficient for a safe tool.

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 focused sentences with no waste. First sentence states purpose, second adds safety and input info, third gives usage advice. 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?

Simple tool with no output schema; description adequately explains return value (Markdown document) and content sections. Could optionally mention approximate length but not necessary.

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?

No parameters exist; description states 'takes no arguments', which matches schema coverage of 100%. Baseline of 4 applies.

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 clearly states the tool returns a Markdown document with specific sections. It distinguishes itself from sibling tools (click, fill, etc.) by emphasizing it is read-only and does not interact with the page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends calling it at the start of a debugging session for unfamiliar users or refresher. Does not list exclusions or alternatives, but the context is clear given sibling tools are all actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_network_requestsA

Return all fetch and XHR requests captured since the bridge connected, including URL, method, HTTP status, duration, request and response headers, and request and response bodies (bodies capped at 10 KB each — anything longer is truncated with a marker; binary responses are summarised). Use this to find failed requests (4xx/5xx), wrong URLs, slow calls, or to inspect what the app actually sent or received. Use 'filter' to narrow by URL/method and 'since' (a ms timestamp) to see only requests that fired after an action. Read-only: it returns a passively captured log and does not issue or modify any requests.

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No	Filter by URL substring or HTTP method, e.g. 'api' or 'POST'
`since`	No	Only requests with ts >= this (ms epoch). Scope to 'what fired after I did X'.

TDQS

A4.7/5.0

Behavior5/5

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

Even without annotations, the description discloses it is read-only, passive, does not issue/modify requests, details body capping (10 KB, truncation marker), and binary summarization. This fully informs the agent of the tool's behavior.

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?

The description is concise and well-structured: first sentence states primary purpose and output, then gives limitations/behavior, then use cases and parameter hints. Every sentence is informative with no redundancy.

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?

Given the tool's simplicity (2 optional params, no output schema), the description covers all needed aspects: what it does, what it returns, limitations, and usage scenarios. An agent can fully understand when and how to invoke it.

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 coverage is 100% with good parameter descriptions. The description adds practical context on how to use parameters for narrowing (e.g., 'filter' by URL/method, 'since' for post-action requests), enhancing the schema's meaning.

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 clearly states it returns all fetch and XHR requests captured, listing specific fields like URL, method, status, headers, and bodies. It distinguishes from sibling tools like get_console_logs or get_html by focusing specifically on network traffic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit use cases are given: find failed requests, wrong URLs, slow calls, inspect sent/received data. It suggests using 'filter' and 'since' parameters for narrowing. While it doesn't explicitly state when not to use it, the context is clear enough for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_page_infoA

Return basic page context: current URL, document title, readyState, viewport size, scroll position, and user agent. Read-only and non-destructive: it only reads page state and makes no changes. Useful to orient at the start of a session or confirm a navigation happened.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

Without annotations, description fully discloses read-only and non-destructive nature, making behavior transparent.

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?

Two sentences, front-loaded with key verb and resource. Every sentence adds value, zero fluff.

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, but description enumerates all return fields (URL, title, etc.), making it complete for a simple info 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?

No parameters; schema coverage 100%. Description adds value by listing returned information, justifying baseline 4.

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?

Clear verb 'Return' and specific resource 'basic page context' with enumerated fields. Distinguishes from siblings (e.g., click, fill) by being read-only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'orient at start of session' or 'confirm navigation'. Lacks when-not or alternatives, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hoverA

Hover over an element by dispatching synthetic, bubbling mouseover and mouseenter events from inside the page. This triggers JavaScript hover handlers (onMouseEnter / onMouseOver), so hover-only UI that mounts on hover (tooltips, popovers, dropdown and submenus) appears in the DOM; follow up with query_dom, get_html, or inspect_element to read what was revealed. Three limits to know: it does NOT activate the CSS :hover pseudo-class (that is driven by the real cursor, not synthetic events), so styles or content shown purely via :hover in CSS will not change; no mouseout / mouseleave is sent, so the hovered state stays until the app tears it down or you interact elsewhere; and the events are dispatched whether or not the element is visible or in the viewport (it is not scrolled into view), so a successful call does not by itself confirm anything rendered. If the selector matches nothing the call returns an error. Returns the tag of the hovered element.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector for the element to hover, e.g. '#menu-trigger' or '.tooltip-anchor'. Target the element that owns the hover handler (often the trigger, not the popup).

TDQS

A4.8/5.0

Behavior5/5

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

No annotations present, so description carries full burden. It fully discloses behavioral nuances: synthetic events, no CSS pseudo-class activation, no mouseout, no viewport scrolling, and error on missing element. No contradictions.

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?

Well-structured with clear purpose, follow-up actions, and limitations. Each sentence adds value, though the explanation of limits could be slightly more compact without losing clarity.

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?

For a complex synthetic event tool, the description covers all critical aspects: behavior, limitations, error handling, and return value (tag of hovered element). No output schema is needed as return is simple.

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 coverage is 100%, but description adds valuable context beyond schema: advises targeting the trigger element (not the popup) and provides CSS selector examples. This enhances understanding of how to use the parameter.

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?

Clearly states the action ('hover over an element') and mechanism ('dispatch synthetic, bubbling mouseover/mouseenter events'). Distinguishes from siblings by focusing on triggering JavaScript hover handlers for UI elements like tooltips and popovers.

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?

Provides explicit guidance on when to use (trigger hover handlers), follow-up actions (query_dom, get_html), and three key limitations (no CSS :hover, no mouseout, no scrolling). Also mentions error handling for unmatched selectors.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_elementA

Return full details about a single element: tag, id, classes, all attributes, text content, bounding rect (top/right/bottom/left/width/height + page scroll and an inViewport flag), a compact ancestor 'path' (e.g. 'body > main > div#app > button.cta'), a curated set of computed styles (layout, box model, typography, positioning, flex/grid), an 'overflow' block when content is clipped/overflowing (scroll vs client size + per-axis x/y flags), a 'clipped' block when an ancestor's overflow cuts the element off (the clipping ancestor + which edges), an effective-visibility check ('visible' boolean, with a 'hiddenReason' such as 'ancestor div#modal display:none' or 'opacity:0' when not visible, accounting for ancestors), an occlusion check ('hittable' boolean from a center-point hit-test, with 'occludedBy' naming the element actually on top when something covers it), an 'a11y' block (resolved role, best-effort accessible name, and key states like expanded/checked/selected/disabled/hidden/tabindex), a 'pseudo' block with ::before/::after content when set (icon fonts, generated text), and live form state where applicable (an input's current value, checked, disabled, etc.). Pass 'properties' to additionally read any specific computed CSS properties by name — they come back under 'requested'. Use this to understand why an element looks wrong or isn't behaving as expected. Read-only: it only reads element state and never changes the page, and it returns an error if the selector matches nothing. Note: addEventListener-registered event handlers cannot be read from the page; only inline on* handler attributes appear (in 'attributes').

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector that should resolve to one element, e.g. '#submit-btn' or 'main .card:first-child'. If several match, the first in document order is inspected.
`properties`	No	Extra computed CSS properties to read by name (kebab-case), e.g. ['transform', 'z-index', 'margin-top']. They come back under a 'requested' object, in addition to the curated default set.

TDQS

A4.6/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It declares read-only ('Read-only: it only reads element state and never changes the page'), notes behavior on no match ('returns an error if the selector matches nothing'), and discloses a limitation ('addEventListener-registered event handlers cannot be read from the page; only inline on* handler attributes appear'). This is comprehensive behavioral disclosure.

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?

The description is dense but front-loaded with the core purpose. Every sentence adds value, listing specific blocks of information (a11y, pseudo, form state). While lengthy, it avoids redundancy and wastes no words. It could be slightly improved with bullet points for readability, but it is structurally effective.

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?

Given no output schema, the description extensively explains the return value: bounding rect, ancestor path, computed styles (layout, box model, etc.), overflow/clip checks, visibility/hit-test, a11y, pseudo, and form state. It also notes the 'requested' property block. The description is self-sufficient and covers all expected aspects.

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 coverage is 100%, so baseline is 3. The description adds value beyond the schema by providing examples for 'selector' ('#submit-btn' or 'main .card:first-child') and explaining the behavior when multiple matches ('the first in document order is inspected'). For 'properties', it clarifies they come back under a 'requested' object. This adds useful semantic context.

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 opens with 'Return full details about a single element' and enumerates an extensive list of specific attributes (tag, id, classes, attributes, text, bounding rect, etc.), clearly stating the verb('return') and the resource('element'). It distinguishes itself from siblings like 'query_dom' by emphasizing a single-element deep inspection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Use this to understand why an element looks wrong or isn't behaving as expected.' It provides a clear use case but does not contrast with alternatives like 'click' or 'hover' or specify when not to use it. The context of deep inspection vs. sibling tools is implied but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

press_keyA

Dispatch a key press (keydown/keypress/keyup) on an element — e.g. Enter to submit a search, Escape to close a modal, Tab to move focus, or ArrowUp/ArrowDown in a list. Use named keys (Enter, Escape, Tab, Backspace, Delete, ArrowUp/Down/Left/Right) or a single character. Note: this fires key handlers but does NOT insert text into inputs — use 'fill' to set an input's value, then press_key for the submit/shortcut. If the selector matches nothing the call returns an error; it dispatches the key events and returns without waiting for any resulting navigation or re-render.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector for the element that receives the key, e.g. '#search-input'. Target a focused or focusable element: Enter on a focused input submits its form, Escape on an open dialog closes it, Tab moves focus to the next element.
`key`	Yes	A named key or a single character. Named keys: Enter, Escape, Tab, Backspace, Delete, ArrowUp, ArrowDown, ArrowLeft, ArrowRight (case-sensitive, as in the DOM KeyboardEvent 'key' value). Any other single character (e.g. 'a', '/') is sent as that character.

TDQS

A4.8/5.0

Behavior5/5

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

No annotations present, so description fully carries behavioral burden. Discloses the sequence of key events (keydown/keypress/keyup), clarifies no text insertion, specifies error on missing element, and notes asynchronous return behavior. Thorough and honest.

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, no wasted words. Critical information is front-loaded (purpose), followed by usage guidance and behavioral notes. Each sentence earns its place.

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?

Given the tool's simplicity (2 params, no output schema), the description covers purpose, usage, behavior, and error handling. Could mention if element must be in view or any additional constraints, but examples imply common UI elements. Sufficient for an agent.

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 coverage is 100%, but description adds value beyond schema: for 'selector' it explains targeting focused/focusable elements; for 'key' it enumerates named keys and case sensitivity. This enhances understanding beyond the schema descriptions.

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?

Description uses specific verb 'Dispatch' and resource 'element', with concrete examples (Enter, Escape, Tab, Arrow keys). Explicitly distinguishes from sibling 'fill' by noting it does not insert text. Clearly states what the tool does and what it does not do.

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?

Provides explicit when-to-use scenarios with examples. States when not to use (for text insertion) and directs to 'fill' as alternative. Also mentions error conditions (selector matches nothing) and that it returns without waiting for navigation/re-render.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_domA

Query the page with a CSS selector and return a summary of every matching element (tag, id, classes, text content). Good for counting list items, checking what's rendered, or finding the right selector before calling inspect_element or click. Read-only: it only reads the DOM and never changes the page. Returns an empty list (not an error) when nothing matches, so it is also a safe existence check.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector matched against the whole document, e.g. '.todo-item', '#search-input', or 'nav a'. Returns every match, so it also works as a count or existence check.

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: it is read-only ('never changes the page'), returns an empty list on no match (not an error), and is safe. This goes beyond basic functionality and provides crucial context for safe usage.

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?

The description is three sentences: first sentence states core action, second gives use cases, third clarifies read-only and empty list behavior. It is front-loaded with the essential purpose, and every sentence adds necessary information without redundancy.

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?

Given the tool has only one simple parameter, no output schema, and no annotations, the description is complete. It covers purpose, usage guidance, return value (tag, id, classes, text content), and safety (read-only, empty list on no match). This is sufficient for an agent to understand and invoke the tool correctly.

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?

The input schema already has a detailed description for the selector parameter, including examples and behavior. The tool description adds value by specifying the return format (tag, id, classes, text content) and clarifying that it returns a summary of every match, which is not in the schema description. This slightly exceeds the baseline of 3 for high schema coverage.

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 clearly states the tool queries the page with a CSS selector and returns a summary of matching elements (tag, id, classes, text content). This specific verb and resource distinguish it from siblings like inspect_element (which does detailed inspection of one element) and get_html (which gets raw HTML).

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?

The description explicitly provides use cases: 'Good for counting list items, checking what's rendered, or finding the right selector before calling inspect_element or click.' It also implies when not to use (e.g., for detailed inspection use inspect_element) and suggests it as a safe existence check, offering clear guidance on when to choose this tool over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reset_overridesA

Undo every set_style / set_attribute / set_text change the bridge has applied since it connected, restoring the original values. Best effort: elements the framework has since re-created may not roll back (a page reload always fully resets).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses limitations (re-created elements may not roll back) and mentions a reliable alternative (page reload). This sufficiently informs the agent of behavioral traits.

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?

Two concise sentences: first states primary purpose, second adds caveat. No unnecessary words, effectively front-loaded.

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?

For a parameterless tool with no output schema, the description fully covers the action, scope, limitations, and alternative reset method. No gaps.

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

Parameters5/5

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

No parameters exist, and schema coverage is 100%. The description adds value by clarifying the action and scope beyond the empty schema.

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 explicitly states the verb 'Undo' and the resources (set_style/set_attribute/set_text changes) with the scope 'since it connected'. This clearly distinguishes it from sibling setter tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'best effort' caveat and notes that a page reload fully resets, providing practical usage context. While it doesn't explicitly list alternatives, the inverse relationship to setters is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_attributeA

Set or remove an attribute on an element to preview a change (toggle disabled, swap a class, set an aria-* attribute). Pass value=null to remove the attribute. Live preview only — not saved to source, resets on reload. If the attribute is one a framework controls (class, value, checked, disabled, …) the result includes a 'frameworkWarning' that it may be reverted on the next render — relay it. Reset with reset_overrides.

ParametersJSON Schema

Name	Required	Description
`selector`	Yes	A CSS selector for the target element, e.g. '#menu' or 'button.cta'. If several match, the first in document order is used.
`name`	Yes	The attribute name to set or remove, e.g. 'disabled', 'class', 'aria-expanded', 'hidden', or a 'data-*' attribute.
`value`	Yes	The new value as a string, or null to remove the attribute entirely. For boolean attributes like 'disabled' or 'hidden', any non-null string (even '') sets them; use null to unset.

TDQS

A4.7/5.0

Behavior5/5

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

No annotations provided, so description fully discloses temporary nature, reset on reload, frameworkWarning behavior, null for removal, and first-element selection. Comprehensive without annotations.

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 focused sentences front-loading the core action, each sentence adds unique value (preview, null for removal, framework warning, companion tool). No redundancy.

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?

For a simple 3-param tool without output schema, description covers return behavior (frameworkWarning), companion tool (reset_overrides), and all parameter semantics fully.

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 coverage is 100%, baseline 3. Description adds nuance like 'null to remove', boolean attribute behavior, and examples for name. Adds meaningful context beyond schema.

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?

Description clearly states the tool sets or removes an attribute for previewing changes, with concrete examples (toggle disabled, swap a class, set aria-*). This distinguishes it from siblings like set_style or set_text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states it's for live preview only and resets on reload, implying not for permanent changes. Mentions reset_overrides but doesn't explicitly compare to other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_styleA

Set one or more inline CSS properties on an element to PREVIEW a visual change live (e.g. shrink a label that doesn't fit, adjust padding or width). This edits the running DOM only — it is NOT saved to source and resets on reload — so tell the user it's a preview, and once they're happy, make the real change in the CSS/component source. Inline styles override the stylesheet and usually survive re-renders. The result includes a 'note' to relay; reset with reset_overrides.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector for the element to restyle, e.g. '#banner' or '.cta'. If several match, the first in document order is used.
`properties`	Yes	A map of CSS property to value, applied as inline styles. Property names are kebab-case and values are full CSS strings, e.g. { 'font-size': '13px', 'white-space': 'nowrap' }. Pass an empty string as the value to clear a single inline property.

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, description fully discloses that changes are ephemeral (not saved, reset on reload), inline styles override stylesheet, survive re-renders, and result includes a 'note' to relay. Provides complete behavioral context.

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?

Description is clear and front-loaded with purpose, but slightly verbose. Could tighten phrasing while retaining all critical information.

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?

For a tool with no output schema and no annotations, the description fully covers behavior, usage, and expected results. Mentions result note and reset alternative, leaving no obvious gaps.

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 coverage is 100%. Description adds extra context: uses first matching element, CSS property values as kebab-case, and empty string clears property. Provides useful but not essential elaboration beyond schema.

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?

Clearly states the tool sets inline CSS properties on an element for previewing visual changes. Distinguishes from sibling reset_overrides and emphasizes it's a preview, not a permanent save.

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?

Explicitly tells when to use (preview changes) and what to do after (make real change in source). Mentions reset_with reset_overrides and advises informing the user about the temporary nature.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_textA

Replace an element's text content to preview wording/label changes. Live preview only — not saved to source, resets on reload. textContent is almost always framework-controlled, so the result includes a 'frameworkWarning' that React/Vue/etc. will likely overwrite it on the next render — relay that, and persist real changes in the source. Reset with reset_overrides.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	A CSS selector for the element to relabel, e.g. '#title' or '.cta-label'. If several match, the first in document order is used.
`text`	Yes	The replacement text, inserted as plain text (not parsed as HTML). Replaces all existing child content of the element.

TDQS

A4.7/5.0

Behavior5/5

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

No annotations, so description carries full burden. Discloses preview-only nature, reset on reload, framework-controlled overwrite behavior, and advises to persist real changes in source. Also mentions reset_overrides tool.

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?

Very concise: two sentences plus a recommendation. Front-loaded with purpose, then critical behavioral traits, then actionable advice. No wasted words.

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?

Tool is simple with two required params and no output schema. Description fully covers preview behavior, framework interaction, and reset capability. No gaps for the intended use case.

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 coverage 100% with clear descriptions. The description adds value beyond schema by noting text is plain text (not HTML) and replaces all existing child content.

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 uses specific verb+resource ('Replace an element's text content') and clearly distinguishes from siblings like set_attribute or set_style by focusing on text content replacement for preview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States it's for live preview only, not saved, resets on reload, and provides frameworkWarning context. Lacks explicit when-not-to-use or alternatives for persistent changes, but implies using source changes instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv0.3.2Jun 23, 2026

Changedclick1 field changed

changedInput schema / properties / selector / description

Previous value: -"CSS selector for the element to click"New value: +"A CSS selector for the element to click, e.g. '#submit-btn' or 'button[type=submit]'. If several match, the first in document order is clicked."

Changedfill2 fields changed

changedInput schema / properties / selector / description

Previous value: -"CSS selector for the input element"New value: +"A CSS selector for the input, textarea, or select to fill, e.g. '#email' or 'input[name=q]'."

changedInput schema / properties / value / description

Previous value: -"Value to type"New value: +"The full value to set. It replaces the field's current contents (it is not appended); for a <select>, pass the target option's value attribute."

Changedget_console_logs2 fields changed

changedInput schema / properties / levels / description

Previous value: -"Restrict to these levels — e.g. ['error'] to skip noisy warn/info/debug"New value: +"Restrict to these levels, e.g. ['error'] to skip noisy warn/info/debug, or ['error', 'warn'] for both. Omit for all levels."

changedInput schema / properties / limit / description

Previous value: -"Return only the N most-recent entries"New value: +"Cap the result to the N most-recent entries, e.g. 50. Omit to return everything captured since the bridge connected."

Changedget_html1 field changed

changedInput schema / properties / selector / description

Previous value: -"CSS selector — should match one element"New value: +"A CSS selector for the region to dump, e.g. '#app' or '.modal'. If several match, the first in document order is used. Scope it tightly: the outerHTML is capped at 50 KB."

Changedhover1 field changed

changedInput schema / properties / selector / description

Previous value: -"CSS selector"New value: +"A CSS selector for the element to hover, e.g. '#menu-trigger' or '.tooltip-anchor'. Target the element that owns the hover handler (often the trigger, not the popup)."

Changedinspect_element2 fields changed

changedInput schema / properties / properties / description

Previous value: -"Extra computed CSS properties to read by name, e.g. ['transform', 'z-index', 'margin-top']"New value: +"Extra computed CSS properties to read by name (kebab-case), e.g. ['transform', 'z-index', 'margin-top']. They come back under a 'requested' object, in addition to the curated default set."

changedInput schema / properties / selector / description

Previous value: -"CSS selector — should match exactly one element"New value: +"A CSS selector that should resolve to one element, e.g. '#submit-btn' or 'main .card:first-child'. If several match, the first in document order is inspected."

Changedpress_key2 fields changed

changedInput schema / properties / key / description

Previous value: -"A key name (Enter, Escape, Tab, ArrowDown, …) or a single character"New value: +"A named key or a single character. Named keys: Enter, Escape, Tab, Backspace, Delete, ArrowUp, ArrowDown, ArrowLeft, ArrowRight (case-sensitive, as in the DOM KeyboardEvent 'key' value). Any other single character (e.g. 'a', '/') is sent as that character."

changedInput schema / properties / selector / description

Previous value: -"CSS selector for the element to receive the key"New value: +"A CSS selector for the element that receives the key, e.g. '#search-input'. Target a focused or focusable element: Enter on a focused input submits its form, Escape on an open dialog closes it, Tab moves focus to the next element."

Changedquery_dom1 field changed

changedInput schema / properties / selector / description

Previous value: -"CSS selector"New value: +"A CSS selector matched against the whole document, e.g. '.todo-item', '#search-input', or 'nav a'. Returns every match, so it also works as a count or existence check."

Changedset_attribute3 fields changed

changedInput schema / properties / name / description

Previous value: -"Attribute name"New value: +"The attribute name to set or remove, e.g. 'disabled', 'class', 'aria-expanded', 'hidden', or a 'data-*' attribute."

changedInput schema / properties / selector / description

Previous value: -"CSS selector — should match one element"New value: +"A CSS selector for the target element, e.g. '#menu' or 'button.cta'. If several match, the first in document order is used."

changedInput schema / properties / value / description

Previous value: -"New value, or null to remove the attribute"New value: +"The new value as a string, or null to remove the attribute entirely. For boolean attributes like 'disabled' or 'hidden', any non-null string (even '') sets them; use null to unset."

Changedset_style2 fields changed

changedInput schema / properties / properties / description

Previous value: -"CSS property → value map, e.g. { 'font-size': '13px', 'white-space': 'nowrap' }"New value: +"A map of CSS property to value, applied as inline styles. Property names are kebab-case and values are full CSS strings, e.g. { 'font-size': '13px', 'white-space': 'nowrap' }. Pass an empty string as the value to clear a single inline property."

changedInput schema / properties / selector / description

Previous value: -"CSS selector — should match one element"New value: +"A CSS selector for the element to restyle, e.g. '#banner' or '.cta'. If several match, the first in document order is used."

Changedset_text2 fields changed

changedInput schema / properties / selector / description

Previous value: -"CSS selector — should match one element"New value: +"A CSS selector for the element to relabel, e.g. '#title' or '.cta-label'. If several match, the first in document order is used."

changedInput schema / properties / text / description

Previous value: -"New text content"New value: +"The replacement text, inserted as plain text (not parsed as HTML). Replaces all existing child content of the element."

16 tool updatesv0.3.1Jun 10, 2026
- First observedclick
- First observedconnection_status
- First observedfill
- First observedget_console_logs
- First observedget_html
- First observedget_instructions
- First observedget_network_requests
- First observedget_page_info
- First observedhover
- First observedinspect_element
- First observedpress_key
- First observedquery_dom
- First observedreset_overrides
- First observedset_attribute
- First observedset_style
- First observedset_text

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool targets a distinct action or data source: click/fill/hover/press_key are different interactions; query_dom/get_html/inspect_element are different DOM inspection methods; get_console_logs/get_network_requests capture different logs; set_style/set_attribute/set_text are different modifications; and helpers like connection_status and get_instructions have unique roles. No two tools overlap in purpose.

Naming Consistency5/5

All tool names use lower_snake_case and follow a verb_noun pattern (e.g., query_dom, get_page_info, set_style). Even connection_status is a clear noun-noun compound, and press_key is verb_noun. The naming is uniform and predictable.

Tool Count5/5

16 tools is a well-scoped set for a browser debugging server. It covers interactions, DOM inspection, logging, overrides, and state checks without being excessive. Each tool serves a clear purpose and the count feels right for the domain.

Completeness4/5

The tool surface is largely complete for debugging: read (DOM, logs, network, page info), interact (click, fill, hover, press_key), and modify (style, attribute, text with reset). Minor gaps exist (no navigate/reload tool, no screenshot), but the core workflow is covered and agents can work around these limitations.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

sncro A
io.github.scottconfusedgorilla
Live browser debugging for AI assistants — DOM, console, network via MCP.
Browser Automation Developer Tools Monitoring
2
render-mcp
io.github.RodRomer
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
61
aiqaramba
io.github.ajrogier
Browser-based QA for AI-built software. Test pages with real browsers via agents.
Testing & QA Tools Browser Automation Agent Orchestration
2
pipehero A
io.github.pipehero
Debug webhooks from your AI agent: inspect and replay captured webhooks on localhost.
Developer Tools API Testing
72

Related MCP Servers

WebEvalAgent MCP Serverofficial
Browser Automation Testing & QA Tools
refreshdotdev
A
license
A
quality
F
maintenance
Unleashes LLM-powered agents to autonomously execute and debug web apps directly in your code editor, with features like webapp navigation, network traffic capture, and console error collection.
Updated 7 months ago (2026-02-11 14:55 UTC)
2
1,240
Apache 2.0
Curupira
Developer Tools App Automation Testing & QA Tools
drzln
A
license
Not graded
quality
D
maintenance
Enables AI assistants to debug frontend applications by providing direct access to browser DevTools, React state, DOM inspection, and runtime debugging capabilities. Bridges the gap between AI and complex web applications for autonomous debugging and issue resolution.
Updated 5 months ago (2026-04-19 02:45 UTC)
MIT
agnt
Developer Tools Browser Automation Code Execution
standardbeagle
A
license
Not graded
quality
A
maintenance
Bridges AI coding agents with the browser to provide visual debugging, real-time error capture, screenshot capabilities, DOM inspection, and interactive wireframing through a reverse proxy with injected developer tools.
Updated a day ago (2026-09-05 05:35 UTC)
58
19
Apache 2.0
console-stream-mcp
Developer Tools Observability
Topman-14
A
license
Not graded
quality
B
maintenance
Enables AI coding agents to access live console logs, errors, and network requests from web applications via a local WebSocket connection, without copying data to chat.
Updated 17 days ago (2026-08-20 01:57 UTC)
27
18
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/feedthrough/feedthrough'

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

Feedthrough

The name

Why Feedthrough?

Packages

Framework support

Quick start

1. Start the MCP server

2. Add it to your MCP client config

3. Inject the bridge into your page

4. Open your page and start asking

MCP tools

Example app

Using with an AI agent

Recommended workflow

Project-memory snippet

Sample system prompt

Security

What gets captured

Development

Releasing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

WebEvalAgent MCP Serverofficial

Latest Blog Posts

MCP directory API