Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ilharp/webview-devtools-mcp --skill webview-devtoolsgit clone --depth 1 https://github.com/ilharp/webview-devtools-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ilharp/webview-devtools-mcp/webview-devtools)<a href="https://agentmods.dev/skills/ilharp/webview-devtools-mcp/webview-devtools"><img src="https://agentmods.dev/badge/skills/ilharp/webview-devtools-mcp/webview-devtools/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ilharp/webview-devtools-mcp/webview-devtools"><img src="https://agentmods.dev/badge/skills/ilharp/webview-devtools-mcp/webview-devtools.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00102 | $0.00985 |
| Opus 5.5 | $0.00041 | $0.00394 |
| Sonnet 5.5 | $0.00020 | $0.00197 |
| Haiku 4.5 | $0.00010 | $0.00098 |
Grade A, and why
webview-devtools scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Core Concepts
Instrumented WebView, not launched Chrome: This skill is for WebViews/pages that already load the wdmcp server’s target.js, for example with <script src="//<host>:<port>/target.js"></script>. The MCP server does not open or navigate a Chrome profile for the user; it starts a local wdmcp server and waits for instrumented targets to connect back. If no target connects, the first tool call times out with guidance to inject target.js.
target.js bridge: target.js is the webview-side bundle. When loaded in the page, it opens a target WebSocket to the wdmcp server, registers page metadata (URL/title/favicon), and runs an in-page CDP backend.
Page availability and lifecycle: list_pages shows currently connected instrumented WebViews. A page appears only while the WebView is open and connected; reloads/disconnects are surfaced as target create/destroy events. Use select_page when multiple WebViews are connected.
Navigation constraints: navigate_page can act only on the currently connected WebView through its in-page backend; it cannot create a fresh browser tab or inject target.js into an unconfigured page for you.
Element interaction: Use take_snapshot to get page structure with element uids. Each element has a unique uid for interaction. If an element isn't found, take a fresh snapshot - the element may have been removed or the page changed.
Environment Readiness
Before using the tools, decide whether the user's target page is already connected or can be connected:
- Confirm the page/WebView is intended to be inspected through this skill.
- Determine the server URL the page should load. Start from the MCP configuration, because the port may not be the default
9333: look for workspace/client config files such as.mcp.json,gemini-extension.json,.claude/settings.json,.vscode/launch.json, or.gemini/settings.json, then inspect the configured command args for--portand--host. - If no configured host/port is found, use the defaults
127.0.0.1:9333. Confirm the page loads that exacttarget.jsURL, for example<script src="http://<host>:<port>/target.js"></script>. - Confirm
<host>:<port>is reachable from the device or runtime that hosts the WebView. For a mobile device, simulator, remote WebView, or embedded app,127.0.0.1usually means the device itself, not the user's development machine; use a reachable host address instead. - If the user has not added
target.jsyet, do not call browser-automation tools first. Explain the injection requirement and help them configure it. - If the user says the page is already configured, use
list_pagesto check connected targets. If no page appears or the first tool call times out, ask the user to open/reload the WebView and verify the injected script URL is reachable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 49 lines · 102 tokens per session scan A 113f8b52c85e
webview-devtools is a skill published in the GitHub repository ilharp/webview-devtools-mcp (2 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 102 tokens to every session and 985 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
chrome-devtools-cli
Use this skill to write shell scripts or run shell commands to automate tasks in the browser or otherwise use Chrome DevTools via CLI.
cookie-debugging
Uses Chrome DevTools MCP for inspecting, debugging, and testing cookies, session state, authentication issues, and cookie consent compliance. Use when diagnosing 401/403 errors, authentication redirects, session expiration, Cookie/Set-Cookie header issues, cookie banner consent conformance, or third-party…
a11y-debugging
Uses Chrome DevTools MCP for accessibility (a11y) debugging and auditing based on web.dev guidelines. Use when testing semantic HTML, ARIA labels, focus states, keyboard navigation, tap targets, and color contrast.
chrome-devtools
Uses Chrome DevTools via MCP for efficient debugging, troubleshooting and browser automation. Use when debugging web pages, automating browser interactions, analyzing performance, or inspecting network requests. This skill does not apply to --slim mode (MCP configuration).
debug-optimize-lcp
Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions…
troubleshooting
Uses Chrome DevTools MCP and documentation to troubleshoot connection and target issues. Trigger this skill when listpages, newpage, or navigatepage fail, or when the server initialization fails.