Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@playwright-vsource Get a proof screenshot of the canonical tag on example.com/products/chair"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that fetches a page's raw HTML the way a real browser does, renders it like Chrome's view-source: (line numbers, monospace), highlights what you're looking for, and saves a screenshot.
It's built for proof screenshots: "the canonical is fixed", "hreflang now points here", "the meta description no longer double-encodes &". Playwright can't open view-source: URLs, so this rebuilds the view instead.
Highlights only the matched text, not the whole line, so long minified lines stay readable.
Plain-text matches also find their JSON-escaped form (/ → \/), so URLs inside JSON-LD are found. Prefix a match with re: for a regex.
By default only the matched lines and their context are shown, with long gaps collapsed into "⋯ N lines hidden".
hide_params sends query parameters (preview tokens, auth keys) but leaves them out of the header.
Saves to ~/Desktop by default, and returns the matched line numbers so you can quote them.
Related MCP server: screenshots-snapshot-site
Requires Node 18+.
git clone https://github.com/devnazir/playwright-vsource.git
cd playwright-vsource
npm install
npx playwright install chromium chromium-headless-shellclaude mcp add playwright-vsource --scope user -- node /absolute/path/to/playwright-vsource/src/index.jsTo also install the skill that tells Claude when and how to use the tools:
mkdir -p ~/.claude/skills
cp -r skills/view-source-proof ~/.claude/skills/{
"mcpServers": {
"playwright-vsource": {
"command": "node",
"args": ["/absolute/path/to/playwright-vsource/src/index.js"]
}
}
}view_source_screenshotArgument | Type | Description |
| string | Page to read the source of. Required. |
| string[] | Text to highlight. |
| number[] | Line numbers to highlight in full. |
| string[] | Query parameters to send but leave out of the header. |
|
|
|
| number | Context lines around each match (default 4). |
| string | Output PNG path. Default |
| string | Suffix for the default filename, e.g. |
| number | Viewport width in px (default 1366). |
Returns the saved path, the URL shown in the header, the HTTP status, and each highlighted line's number and text.
view_source_findSame url, match, lines and hide_params arguments. Returns the matching line numbers and text without taking a screenshot, so you can check a match before shooting.
npm run shot -- https://example.com/products/chair \
--match 'rel="canonical"' \
--match 're:<meta name="description"[^>]*>' \
--hide preview_token \
--context 3 \
--out ~/Desktop/canonical.pngOptions: --match (repeatable), --line (repeatable), --hide (repeatable), --context, --mode, --width, --label, --out.
The screenshot is a rendering of the source, not a capture of Chrome's own view-source window. The content and line numbers are exactly what the server returned to a real browser.
The source is fetched from inside a real Chromium page after loading the URL, so cookies set on that load (preview sessions, consent) apply. A CDN or bot protection may still serve a browser something different from what curl or a search crawler gets.
The browser is started on first use and reused until the server exits.
MIT
Fetch a page's raw HTML the way a browser does and return the line numbers and text of matches, without taking a screenshot.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL to read the raw HTML source of. | |
| lines | No | Line numbers to highlight in full. | |
| match | No | Text to highlight. Plain text also matches its JSON-escaped form (/ as \/). Prefix with "re:" for a regex. | |
| hide_params | No | Query parameter names to keep out of the view-source header (they are still sent with the request), e.g. preview or auth tokens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden and does well: it explains that the page is fetched like a browser, that raw HTML is used, and that matches are returned as line numbers and text. It leaves out authentication, error, or rate-limit behavior, but covers the core read behavior clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence with no wasted words. The key behavior and sibling contrast are both conveyed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no output schema and no annotations, the description gives enough context about the return shape and the browser-like fetch method. It does not explain output formatting or failure modes, but it covers what an agent needs to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents url, lines, match, and hide_params. The description aligns with the match/line-number behavior but adds no parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: fetch a page's raw HTML, then return line numbers and text of matches. The phrase 'without taking a screenshot' distinguishes it from the sibling view_source_screenshot tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention of not taking a screenshot implies this is the source-inspection alternative to view_source_screenshot, but it does not explicitly say when to choose this tool versus the screenshot tool. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page's raw HTML the way a browser does, render it like Chrome's view-source (line numbers, monospace), highlight matches and save a PNG. Returns the file path and the matched lines.
| Name | Required | Description | Default |
|---|---|---|---|
| out | No | Output PNG path. Defaults to ~/Desktop/vsource-<host-path>-<time>.png. | |
| url | Yes | Page URL to read the raw HTML source of. | |
| mode | No | "matches" (default) shows only the highlighted lines plus context, with long gaps collapsed; "first" is one viewport of the full source scrolled to the first match. | |
| label | No | Suffix for the default filename, e.g. "before" or "after". | |
| lines | No | Line numbers to highlight in full. | |
| match | No | Text to highlight. Plain text also matches its JSON-escaped form (/ as \/). Prefix with "re:" for a regex. | |
| width | No | Viewport width in px (default 1366). | |
| hide_params | No | Query parameter names to keep out of the view-source header (they are still sent with the request), e.g. preview or auth tokens. | |
| context_lines | No | Lines of context above and below the matches (default 4). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavior, and it does disclose that a PNG file is written to disk and that the file path plus matched lines are returned. It leaves gaps around fetching behavior — 'the way a browser does' is ambiguous about whether JavaScript executes — and says nothing about authentication, redirects, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and ending with the return values. There is no filler and every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter tool with fully documented schema and no output schema, the description covers the action, the side effect of writing a file, and the return shape. The main remaining gap is the absence of any guidance relative to view_source_find, which matters given they overlap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every one of the nine parameters, including mode's enum and the match regex prefix, is already documented in structured fields. The description's mention of 'highlight matches' and the returned path adds nothing beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb chain and resource: fetch a page's raw HTML, render it view-source style, highlight matches, and save a PNG. That is clearly distinguishable from a generic page screenshot. It does not, however, distinguish itself from the sibling view_source_find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is for capturing a visual of source with highlights, but there is no explicit when-to-use or when-not guidance. The sibling view_source_find is never mentioned, so the agent has no stated rule for choosing between searching source and screenshotting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0view_source_findview_source_screenshotScored across 2 tools
The tools are mostly distinguishable: one produces a rendered view-source screenshot with highlighted matches, while the other returns match line numbers and text without a screenshot. They overlap in fetching raw HTML and searching for matches, but the output difference is clear enough for selection.
Both tools use the same predictable view_source_ prefix followed by a descriptive suffix. The naming is consistent and clearly communicates the shared domain plus the specific operation.
Two tools is thin for the server's apparent scope, though each covers a distinct output mode. It is workable but borderline sparse, with limited flexibility beyond the screenshot/no-screenshot split.
The surface covers the core purpose: fetching raw HTML and either producing a rendered screenshot with highlighted matches or returning matching lines. Minor gaps exist, such as plain source retrieval or more flexible search/output options, but the main workflow is covered.
Render-and-verify API: HTML/CSS to image or PDF, screenshot any URL, confirm the text rendered.
Search the source code (HTML, JavaScript, CSS) of hundreds of millions of websites.
Pixel-perfect webpage screenshots rendered in a real browser, full-page or viewport, via one POST.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
