Blnq Studio

Accessible-by-default web building. Blnq exposes its editor, live preview and WCAG audit to browser agents via WebMCP — so the AI that writes your code also catches its a11y violations.

Comment

Inspiration

I built blnq.studio because front-end work had become a pile of tabs: an editor, a dev server, a browser, DevTools, an accessibility checker, a design spec, and now an AI chat window that can't see any of them. Every one of those handoffs is where quality leaks out — especially accessibility, which is the first thing dropped when you're moving fast and the last thing an AI agent notices, because it can't see what it built.

I wanted a single tab where the code, the live preview, the audit and the AI all look at the same thing. WebMCP was the missing piece: it lets the editor tab itself become the tool surface an agent uses, so the loop closes without any extra setup.

What it does

blnq.studio is a browser-based editor purpose-built for front-end: code, preview, ship — all in one tab.

  • Live multi-file editing — Monaco under the hood, real HTML/CSS/JS files with folders and ES module imports, no build step. The preview updates as you type.
  • Accessibility first — every preview refresh runs the pour engine against WCAG 2.0–2.2 A/AA plus best-practice rules. The A11y panel lists each violation with its impact, a plain-English fix and the exact element. Colour-contrast checks are built into the editor, not bolted on afterwards.
  • Multi-device preview — switch viewports, check every breakpoint, see the FPS overlay, all without leaving the tab.
  • Design systems your AI respects — drop a DESIGN.md at the project root and the editor treats it as the source of truth: colour and font literals that drift from your tokens get flagged, so AI-written CSS stays inside the system instead of inventing new values.
  • Baseline compatibility — a built-in tool tab tells you which features you're using aren't yet widely available across browsers.
  • Collaborate and fork — real-time multi-cursor collaboration over Yjs, forks and merge requests, a community showcase.
  • Ship from the editor — push to GitHub, deploy from the menu, or download the whole project as one self-contained HTML file.
  • AI & MCP, on your terms — AI is optional. When you want it, connect Claude Code (or any MCP client) over the built-in MCP server, use the in-editor chat with your own model, or — new for this challenge — turn on WebMCP and let a browser-native agent drive the tab directly.

WebMCP: the editor tab is the tool server

Click Start WebMCP and blnq registers 30+ tools with the browser via document.modelContext. No MCP ID, no config file, no separate process. An agent running in the browser can then:

  1. Read and edit files by line range or find-and-replace, with undo snapshots and live edits landing in the editor and preview
  2. See what it built — blnq_screenshot returns a real PNG, plus element inspection, console errors and viewport switching
  3. Audit with blnq_check_preview, which returns JS errors, every WCAG violation with its element HTML and fix hint, and any design-token drift
  4. Interact — click, type, press keys, wait for elements — so it can tab through a form or open a modal and re-audit the new state
  5. Fix and re-audit until the report is clean

The key design decision was that WebMCP isn't a separate integration. blnq has one shared tool registry; the MCP server and the WebMCP endpoint are two thin adapters over it. A tool added to the registry appears in both, and edits behave identically — same validation, same undo, same activity toasts, same prompt history — whichever transport the call came in on.

How I built it

blnq is an Express + Monaco + Yjs app with a plugin system; the MCP server, AI chat, Baseline and spellcheck tools are all plugins. The accessibility engine runs inside the preview iframe and posts results up to the editor, so the panel a human reads and the result an agent reads come from the same run.

WebMCP was around 350 lines: a client module that fetches tool descriptors and calls registerTool() for each (with readOnlyHint annotations and MCP-shaped { content } results including images), and a server endpoint that Zod-validates and runs the shared handler. The endpoint is same-origin only and still requires the tab's random bridge ID; the browser handles user consent on its side.

What I learned

The accessibility audit turned out to be the most valuable thing blnq can hand an agent. A screenshot tells a model roughly what it built; a WCAG report with the offending element and a fix hint tells it exactly what to change. Structured, model-readable audit output beat any amount of prompt engineering.

And WebMCP inverts the usual relationship: the page stops being something an agent scrapes and becomes something it calls. Once you have a decent tool registry, the browser becomes the integration layer for free.

What's next

  • Structured JSON from blnq_check_preview so agents can diff violations between audits
  • A blnq_fix_a11y tool that applies remedies for common rule classes automatically
  • Focus-order and keyboard-navigation audits driven by key-press sequences
  • Ship the Chrome origin-trial token on blnq.studio so WebMCP works without flags
  • Share a collaboration session with an agent so humans and AI can work on the same project live

Built With

Share this project:

Updates