Your site reports three different tool counts. Here's what I could actually verify, and a plan for the rest.

A REST-style reference (auth, endpoints, rate limits) doesn't describe a tool that makes zero server calls. Here's the split I'd suggest instead.

One shape, applied to every client-side tool, so 130 pages read as one coherent reference instead of 130 one-offs.

Name & purpose

Tool name plus a one-line statement of what it does.

Category

Which of the site's existing groupings it sits in (Developer & Technical, SEO & Content, etc.) — keeps navigation and cross-links consistent.

How it processes data

The client-side technique or library involved, and an explicit "nothing leaves your browser" statement where true — this is the one line every tool page should share.

Inputs

Every field the tool takes, field-by-field, pulled from the live form — not assumed.

Output

Format, dimensions or size, and what happens on download or copy.

Constraints & edge cases

The caveats that matter before someone relies on the output — the QR page's own "reality check" section is the right model.

Embed / reuse notes

Filled in once I've read the tool's actual source — flagging this honestly rather than guessing at a JS API that may not exist.

Related tools

2–4 real internal links to tools that pair naturally — the contextual linking you asked for, done the way qr-generator already does it.

Live page

Direct link to the working tool.

Screenshot

Auto-captured — see the Screenshots tab.

Last verified

Date I last checked the live page against this entry — so nothing here goes stale the way the Link Status Report did.

The template above, filled out for one real tool — written from the live page, not the repo's marketing copy.

Every tool I could confirm live, grouped the way your own site groups them, plus the 4 sitewide systems. Progress saves automatically in this document.

Straight answer first: I can't run Playwright myself. My code environment has no live internet access, so I can't open your pages or capture anything from them directly.

// Reads a { slug, url } list and screenshots each live page.
// Point TOOLS at your real assets/js/search-data.js TOOLS_INDEX once confirmed.
const { chromium } = require('playwright');
const fs = require('fs');
const path = require('path');

const OUT_DIR = path.join(__dirname, '..', 'docs-assets', 'screenshots');
const TOOLS = require('../data/doc-tools-list.json'); // [{ slug, url }, ...]

(async () => {
  fs.mkdirSync(OUT_DIR, { recursive: true });
  const browser = await chromium.launch();
  const page = await browser.newPage({ viewport: { width: 1280, height: 800 } });

  for (const tool of TOOLS) {
    try {
      await page.goto(tool.url, { waitUntil: 'networkidle', timeout: 30000 });
      await page.screenshot({
        path: path.join(OUT_DIR, `${tool.slug}.png`),
        fullPage: true
      });
      console.log(`saved: ${tool.slug}`);
    } catch (err) {
      console.error(`failed: ${tool.slug} — ${err.message}`);
    }
  }

  await browser.close();
})();

name: Update doc screenshots
on:
  workflow_dispatch: {}
  schedule:
    - cron: '0 3 * * 1'   # weekly, Monday 03:00 UTC

jobs:
  screenshot:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install playwright && npx playwright install --with-deps chromium
      - run: node scripts/capture-doc-screenshots.js
      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "docs: refresh tool screenshots"
          file_pattern: docs-assets/screenshots/*.png

Swap data/doc-tools-list.json for the real path once you confirm it — your own README points to assets/js/search-data.js and its TOOLS_INDEX array as the canonical tool list, which is the right source to generate this from rather than maintaining a second list by hand.