DEV Community: UnitBuilds

DROP YOUR BILL BY 90%

UnitBuilds — Tue, 26 May 2026 23:50:46 +0000

No seriously, 90+% reduction in browser token usage, using AOM instead of DOM

You need this... https://dev.to/unitbuilds_cc/stop-giving-llms-raw-html-build-a-graph-native-96-more-efficient-mcp-web-browser-4h5d

UnitBuilds — Tue, 26 May 2026 23:40:57 +0000

UnitBuilds for UnitBuilds CC

May 26

Stop Giving LLMs Raw HTML: Build a Graph-Native, 96% More Efficient MCP Web Browser

#llm #mcp #neo4j #go

4 min read

If you're using AI, YOU NEED THIS!

UnitBuilds — Tue, 26 May 2026 22:57:22 +0000

mcp-lite

Drop your AI-browsing consumption by up over 90%

Stop Giving LLMs Raw HTML: Build a Graph-Native, 96% More Efficient MCP Web Browser

UnitBuilds — Tue, 26 May 2026 22:49:17 +0000

As developers building AI agents, we’ve all run into the same massive bottleneck: how do you let a Language Model (LLM) browse the web without destroying your API budget or driving execution latency through the roof?

Most current agent frameworks solve web browsing in one of two ways:

Raw HTML Scraping: Injecting hundreds of thousands of tokens of raw HTML (complete with styling classes, analytics scripts, and SVG paths) straight into the context window.
Visual Screenshotting: Sending high-resolution images to a Vision LLM (VLM) and hoping it doesn't hallucinate element coordinates when clicking buttons.

Both methods are slow, expensive, and fragile.

Today, we’re open-sourcing MCP Lite—a standalone, graph-native Model Context Protocol (MCP) browser automation server written in Go. By utilizing Chrome’s Accessibility Object Model (AOM), custom stealth extensions, and Neo4j graph transition mapping, we reduced the context footprint by up to 96.7% and achieved a 3.0x execution speedup.

Here is how we built it, the benchmarks we hit, and how you can use it in your agent stack.

The Core Architecture: Semantic AOM Pruning

When a human looks at a webpage, they don't read the raw HTML code. They look for interactive components: buttons, text fields, links, and headers. Chrome’s accessibility engine translates the visual DOM into a structured Accessibility Object Model (AOM) for screen readers.

MCP Lite taps directly into Chrome's AOM via chromedp. We extract this tree and apply a recursive pruning filter:

Prune Non-Semantic Nodes: We strip away generic containers, layout tables, and presentation divs.
Redundant Flattening: If a link contains a single text child with the same label, we flatten it.
Retain Spatial Bounding Boxes: We keep physical screen coordinates (x, y, width, height) only for actionable nodes.

Here is the visual lifecycle of a page representation as it moves through the pruning pipeline:

graph TD
    HTML["Raw HTML / DOM (100K+ Tokens)"] -->|CDP Session| AOM["Accessibility Object Model (AOM)"]
    AOM -->|Pruning & Redundancy Filter| Pruned["Pruned AOM (90%+ Token Reduction)"]
    Pruned -->|Targeted Clicks| Action["Logical Clicks (nodeId)"]
    Pruned -->|SHA-256 Signature| Hashing["Deterministic State Hashing"]

The Impact: Wikipedia & GitHub Benchmarks

We ran our benchmarking engine against real-world targets comparing the pruned AOM against standard full-HTML extraction:

Target Site	Metric	Standard Full-HTML	MCP Lite (Pruned AOM)	Token Savings / Speedup
wikipedia.org	Payload Size Est. Tokens	435 KB 108,863	47 KB 11,956	89.02% reduction in input tokens
	Latency (3 Steps)	9.0s (100% Agent Loop)	3.0s (0% Agent Loop)	3.0x speedup via workflow playback
github.com	Payload Size Est. Tokens	594 KB 148,625	19 KB 4,774	96.79% reduction (Perfect for modern SPAs)

Instead of feeding 148,000 tokens to the LLM for a single GitHub page, the agent only processes 4,770 tokens—making inference faster and significantly cheaper.

Bypassing Bot Detection: Hardening Chrome

Automating browsers usually triggers bot protection (Cloudflare, DataDome, etc.). MCP Lite loads a custom content script extension (inject.js) at startup that executes at document_start across all frames:

navigator.webdriver Masking: Instead of just overriding the property, we mock the getter. If a bot detector calls .toString() on navigator.webdriver, our mock returns the exact native string signature:

   function get webdriver() { [native code] }

PluginArray Prototype Realignment: Standard mock scripts fail checks like navigator.plugins instanceof PluginArray. We reconstruct the fake plugins list and link their prototypes directly to PluginArray.prototype and Plugin.prototype.
Permissions Query Alignment: We align Notification.permission and navigator.permissions.query to resolve to prompt, matching real browser configurations.

The result? A 100% green pass on benchmarks like bot.sannysoft.com and seamless access to sites like G2.com.

Graph-Native Navigation Mapping

Every web interaction is a state transition. When the agent clicks a button, the page layout changes.

MCP Lite integrates with Neo4j to represent these layouts as nodes and interactions as edges. At every page load:

We compute a SHA-256 hash of the serialized pruned AOM structure to represent the page’s unique layout State.
We log transitions as an INTERACTED edge:

MERGE (f:State {hash: $from})
MERGE (t:State {hash: $to})
MERGE (f)-[r:INTERACTED {role: $role, name: $name, index: $index}]->(t)
SET r.x = $x, r.y = $y, r.w = $w, r.h = $h

If an agent needs to navigate from its current page to a target URL, it queries Neo4j for the shortest path of logical interactions (e.g. "click Search -> type username -> click Submit") and replays them instantly, avoiding reasoning loops.

Replaying Workflows with Zero LLM Overhead

For repetitive automation (such as bulk form submissions or multi-page scrapes), running the LLM in a step-by-step loop is expensive.

MCP Lite includes a workflow engine:

Record: Call workflow_record_start and perform actions.
Template: Actions are written to a JSON file. Use double-braces ({{variable_name}}) to define input fields.
Replay: Play back the workflow with an input dataset:

[
  {"search_query": "adidas campus green"},
  {"search_query": "nike air force white"}
]

The browser handles the automation loop natively, feeding variables into the template and running actions sequentially with 0% LLM overhead during playback.

Try It Yourself!

The repository is open-source under the GNU AGPL-v3 license.

Quick Build

git clone https://github.com/UnitBuilds-CC/MCP-Lite.git
cd mcp-lite
go mod tidy
build.bat # Rebuilds server, benchmark, and test binaries

Configure Claude Desktop

Add it to your claude_desktop_config.json:

{
  "mcpServers": {
    "agentic-browser-mcp-lite": {
      "command": "C:\\path\\to\\mcp-lite\\mcp-server.exe",
      "env": {
        "NEO4J_URI": "bolt://localhost:7687",
        "NEO4J_USER": "neo4j",
        "NEO4J_PASS": "secure_password"
      }
    }
  }
}

Check out the code, run the benchmark suite against your own target sites, and join us in building a more efficient web automation standard!

Star MCP-Lite on GitHub

UnitBuilds-CC / MCP-Lite

AOM driven Agentic browser MCP

Agentic Browser (MCP Lite) 🚀

A highly-efficient, standalone, graph-native version of the Agentic Browser MCP Server. It provides direct LLM control over Google Chrome via the Model Context Protocol (MCP) using chromedp. It integrates with Neo4j to build site graphs, query shortest action paths, and automate complex workflows with looping and parameter binding.

Features

Raw MCP Browser Automation: Perform standard interactions (navigate, click, type, scroll, wait, drag, screenshot, list frames) using standard logical pixel offsets.
Neo4j Graph Logging: Automatically logs page navigation data (titles, links, scripts, and cookies) and AOM state-transition graphs directly to a Neo4j database.
BFS Site Crawling: Traverses a site using Breadth-First Search (BFS) to map structural accessibility states and link action transitions.
Shortest Path Execution: Query Neo4j for the shortest sequence of actions from any start state/URL to a target state/URL, and execute the transitions automatically.
Workflow Recording & Execution…

View on GitHub

Discussion

How are you currently handling web browsing for your AI agents? Are you hitting context limits with raw HTML, or have you tried vision-based approaches?

I'd love to hear your thoughts on using the AOM vs. the DOM for these types of workflows!

I'd have thought more people would be interested in the obliteration of WASM's poor performance? https://dev.to/unitbuilds_cc/how-i-bypassed-blazor-webassemblys-virtual-dom-using-raw-wasm-pointers-4jn7

UnitBuilds — Tue, 26 May 2026 20:52:57 +0000

UnitBuilds for UnitBuilds CC

May 24

How I bypassed Blazor WebAssembly's Virtual DOM using raw WASM pointers

#blazor #webassembly #performance #csharp

4 min read

V.A.L.I.D.

UnitBuilds — Sun, 24 May 2026 18:15:51 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built V.A.L.I.D. (Vectorized Asynchronous Logic & Intelligent Diagnostics) — a lightweight, high-performance state-tracking and business logic framework for .NET 8 and Blazor WebAssembly applications.

Enterprise .NET frameworks like CSLA or state containers like Fluxor are heavily dependent on reflection and heap-allocated tracking collections. V.A.L.I.D. replaces all of that with a zero-allocation compile-time model:

Bitmask Register State Tracking: Uses System.UInt128 bitmasks to track up to 128 property flags (dirty, error, busy, deleted) in $O(1)$ time with 0 B allocated.
VDOM & JS Serialization Bypass: Allocates a contiguous native memory slab (UnmanagedSlab) on the WebAssembly linear heap. A JavaScript requestAnimationFrame render loop directly reads the WASM heap (HEAPU8) to surgically update elements, bypassing Blazor's Virtual DOM diffing.
Roslyn Source Generator: Generates the properties, circular undo/redo history, F# record mappings, and auto-generates unit/fuzz tests.
F# Rules Engine: Projects C# states onto immutable F# struct records, resolving offline-first replication conflicts with mathematical Add-Wins Observed-Removed Set (AWORSet) CRDTs.

Demo

GitHub Repository: UnitBuilds-CC/V.A.L.I.D.
Official Documentation: V.A.L.I.D. Wiki

Architecture Overview

Below is the visual flow of our surgical WASM bypass architecture:

Performance Benchmarks

Here are the official BenchmarkDotNet results comparing V.A.L.I.D.'s direct memory write speed against standard Blazor VDOM mutations:

Benchmark Operation	Execution Time (Mean)	Gen 0 / 1000	Allocated Memory	Speedup
VALID Slab direct memory write	6.62 ns	-	0 B	26.7x
F# Rule Evaluation	15.80 ns	-	0 B	10.4x
F# CRDT Convergence	86.48 ns	0.0391	328 B	1.8x
Blazor VDOM Mutation (Baseline)	172.78 ns	0.0048	40 B	Baseline

The Comeback Story

Before the challenge, V.A.L.I.D. was an experimental proof-of-concept sitting unfinished in my local directory. The code had compilation bugs, the packaging configuration was broken, and the JS-WASM bridge was prone to memory allocation crashes when the WASM memory buffer resized.

Here is what we did to cross the finish line:

Refactored core library dependencies to support clean .NET 8 builds and verified 100% test coverage.
Fixed the JS memory relocation bug in our surgical bridge (vavid-bypass.js). We added a background heartbeat inspector that checks a magic pulse header in WASM memory, allowing the JS loop to automatically re-bind to the heap if the WASM buffer resizes.
Structured the NuGet packaging pipelines and versioned the assets (VALID 3.0.3 and VALID.FSharp 3.0.1).
Created the official release pipeline, pushing tagged releases (v3.0.3) and uploading .nupkg assets to the release tab.
Wrote a 6-page comprehensive Wiki covering Core Concepts, Getting Started, Business Objects, Validation Rules, and Blazor Integration.
Populated the GitHub Projects board with the Blazor Cashbook Demo to give developers a working sandbox.

My Experience with GitHub Copilot

GitHub Copilot acted as an invaluable co-pilot throughout the final polishing process:

Writing Boilerplate & Generators: Copilot expedited the creation of the Roslyn Source Generator syntax trees, writing the recursive C# property-to-bit mapping code in minutes.
Debugging Low-Level JS-Interop: Copilot helped write the safety heartbeat and pointer relocation code in JavaScript, ensuring the WASM HEAPU8 array offset changes were handled gracefully.
Documentation & Wiki Generation: Copilot read our codebase and compiled clear, concise API documentation for our Wiki pages, ensuring the migration path from legacy frameworks (like CSLA) was fully documented.

How I bypassed Blazor WebAssembly's Virtual DOM using raw WASM pointers

UnitBuilds — Sun, 24 May 2026 17:53:21 +0000

The Bottleneck
Step 1: The Memory Slab
Step 2: JSExport Bridge
Step 3: DOM Mutation
The Performance Payoff
Compile-time Generation with Roslyn
Try it yourself!

The Bottleneck: When WebAssembly UI gets sluggish

If you've ever built a heavy data grid, a real-time telemetry dashboard, or a line-of-business spreadsheet application in Blazor WebAssembly, you've likely hit the rendering wall.

Blazor WASM is incredibly productive, but when thousands of cells change multiple times a second:

Every property change triggers an event.
Every event triggers standard Blazor component cycle overhead (StateHasChanged).
The Virtual DOM (VDOM) diffs the old rendering tree with the new one.
JS-Interop serializes the diffs and updates the browser DOM.

Under high frequency (like 100+ updates per second on 5,000+ fields), this pipeline stutters. The CPU spikes to 100%, garbage collection (GC) triggers pauses, and key-press latency rises.

We decided to see if we could completely bypass Blazor's rendering pipeline while maintaining C# as the single source of truth for business logic.

Our solution is V.A.L.I.D.—a compile-time state-tracking framework that shares raw WebAssembly memory slabs directly with JavaScript.

Step 1: The Unmanaged Memory Slab in C

To avoid heap allocations and GC overhead when managing object states (dirty, error, busy, deleted), we allocate a contiguous block of native memory on the WebAssembly linear heap.

We built a custom bump allocator wrapper called UnmanagedSlab<T> that uses NativeMemory.Alloc:

public unsafe class UnmanagedSlab<T> : IDisposable where T : unmanaged
{
    private T* _pointer;
    private readonly int _length;

    public UnmanagedSlab(int length)
    {
        _length = length;
        // Allocate contiguous memory in the WASM heap
        _pointer = (T*)NativeMemory.Alloc((nuint)length, (nuint)sizeof(T));
    }

    public ref T this[int index] => ref _pointer[index];

    public void* GetUnsafePointer() => _pointer;

    // Dispose calls NativeMemory.Free...
}

Every business object in the application is registered to a fixed slot in this slab. Its state flags are represented as single bits in a System.UInt128 mask register, giving us up to 128 fields tracked per object in O(1) time with 0 heap allocations.

Step 2: The JSExport Bridge

Next, we need to let JavaScript know where this memory block is. We use .NET 8's new JS interop system with [JSExport] inside our WebWorkerBridge class:

public static partial class WebWorkerBridge
{
    private static UnmanagedSlab<System.UInt128>? _stateSlab;

    [JSExport]
    public static unsafe nint GetStatePointer()
    {
        if (_stateSlab == null) return 0;
        return (nint)_stateSlab.GetUnsafePointer();
    }
}

When our Blazor page initializes, we retrieve this pointer and pass it directly to JS as a long integer address:

var ptr = WebWorkerBridge.GetStatePointer();
var len = WebWorkerBridge.GetSlabLength();
await JSRuntime.InvokeVoidAsync("__VAVID_INITIALIZE_INDUSTRIAL_BYPASS__", (long)ptr, len);

Step 3: Surgical DOM Mutation in JS

Once JavaScript receives the memory address, it connects to Mono's WebAssembly linear heap buffer (HEAPU8 array).

First, we compile a surgical map of DOM inputs. Every VavidInput.razor component renders standard metadata data-attributes rather than binding inputs to Blazor:

<input class="vavid-control"
       value="@Value"
       data-vavid-slab-index="@SlabIndex"
       data-vavid-bit="@BitIndex" />

Our JS code parses these elements on startup and runs a high-performance requestAnimationFrame loop.

Because we know the exact byte offsets, JS can read the dirty/error/busy bitmasks directly from the heap array and surgically toggle class names without going through the VDOM:

function syncSurgicalMap() {
    const h = globalThis.Module ? globalThis.Module.HEAPU8 : null;
    const base = statePointer; // the nint address from C#

    for (let i = 0; i < surgicalMap.length; i++) {
        const entry = surgicalMap[i];
        const ptr = base + entry.offset; // slot offset

        // Read dirty and error bit flags directly from WASM memory
        const isDirty = (h[ptr + entry.bitByte] & entry.bitMask) !== 0;
        const hasError = (h[ptr + 32 + entry.bitByte] & entry.bitMask) !== 0;

        // Toggle UI classes instantly in place
        const el = entry.el;
        if (isDirty) el.classList.add('vavid-dirty'); else el.classList.remove('vavid-dirty');
        if (hasError) el.classList.add('vavid-error'); else el.classList.remove('vavid-error');
    }
}

The Performance Payoff

We ran micro-benchmarks comparing this bypass model to standard Blazor VDOM mutation and F# rules engines:

Method	Mean	Gen 0 / 1000	Allocated	Speedup
VALID Slab direct memory write	6.62 ns	-	0 B	26.7x
F# Rule Evaluation	15.80 ns	-	0 B	10.4x
Blazor VDOM Mutation (Baseline)	172.78 ns	0.0048	40 B	Baseline

At 6.6ns per update with 0 bytes allocated, state tracking is running at register-level CPU efficiency.

By avoiding Blazor's entire component render cycle, UI grids can handle millions of visual updates with zero input latency.

Compile-time Generation with Roslyn

Writing manual pointer offsets and bit masks by hand for every class is exhausting. To keep the developer experience clean, we built a Roslyn Source Generator.

All you do is write a partial class:

[ValidObject]
public partial class Invoice
{
    [Required]
    public string CustomerName { get; set; } = "";

    [Range(0, 10000)]
    public decimal Amount { get; set; }
}

The source generator intercepts this at build time and generates the bitmask backing properties, circular undo/redo history, F# record projections, and auto-generates unit/fuzz tests right into your test projects.

Try it yourself!

V.A.L.I.D. is fully open-source. If you want to check out the WASM memory management, review the source generators, or run the Blazor grid benchmark locally, check out the repository:

UnitBuilds-CC / V.A.L.I.D.

V.A.L.I.D. (Vectorized Asynchronous Logic & Intelligent Diagnostics)

V.A.L.I.D. is a high-performance, low-latency business logic framework for .NET. It replaces standard reflection-based change tracking with a compile-time, bitmask-driven, and compiler-integrated architecture.

Built specifically for complex enterprise data management, V.A.L.I.D. ensures surgical precision in synchronization and real-time visibility in the browser.

⚡ Performance Benchmarks

V.A.L.I.D. is engineered for absolute zero-allocation on core operations. Below are the official BenchmarkDotNet results comparing V.A.L.I.D.'s direct memory write speed against other state-management components:

BenchmarkDotNet v0.13.12, Windows 11 (10.0.29591.1000)
.NET SDK 10.0.200-preview.0.26103.119
  [Host]     : .NET 8.0.24 (8.0.2426.7010), X64 RyuJIT AVX2
  DefaultJob : .NET 8.0.24 (8.0.2426.7010), X64 RyuJIT AVX2

Method	Mean	Error	StdDev	Gen0	Allocated
VALID Slab direct memory write	6.619 ns	0.1573 ns	0.2305 ns	-	- (0 B)
F# Rule Evaluation	15.800 ns	0.3659 ns	0.7308 ns	-	- (0 B)
F# CRDT Convergence	86.478 ns	1.7367 ns	3.7384 ns	0.0391	328 B
Blazor VDOM Mutation

…

View on GitHub

I’d love to hear your thoughts on this. Is sharing raw pointers with JS in WebAssembly too unsafe for typical business applications, or is the performance payoff worth the trade-off?

DEV Community: UnitBuilds

DROP YOUR BILL BY 90%

You need this... https://dev.to/unitbuilds_cc/stop-giving-llms-raw-html-build-a-graph-native-96-more-efficient-mcp-web-browser-4h5d

Stop Giving LLMs Raw HTML: Build a Graph-Native, 96% More Efficient MCP Web Browser

If you're using AI, YOU NEED THIS!

Stop Giving LLMs Raw HTML: Build a Graph-Native, 96% More Efficient MCP Web Browser

The Core Architecture: Semantic AOM Pruning

The Impact: Wikipedia & GitHub Benchmarks

Bypassing Bot Detection: Hardening Chrome

Graph-Native Navigation Mapping

Replaying Workflows with Zero LLM Overhead

Try It Yourself!

Quick Build

Configure Claude Desktop

UnitBuilds-CC / MCP-Lite

AOM driven Agentic browser MCP

Agentic Browser (MCP Lite) 🚀

Features

Discussion

I'd have thought more people would be interested in the obliteration of WASM's poor performance? https://dev.to/unitbuilds_cc/how-i-bypassed-blazor-webassemblys-virtual-dom-using-raw-wasm-pointers-4jn7

How I bypassed Blazor WebAssembly's Virtual DOM using raw WASM pointers

V.A.L.I.D.

What I Built

Demo

Architecture Overview

Performance Benchmarks

The Comeback Story

My Experience with GitHub Copilot

How I bypassed Blazor WebAssembly's Virtual DOM using raw WASM pointers

Table Of Contents

The Bottleneck: When WebAssembly UI gets sluggish

Step 1: The Unmanaged Memory Slab in C

Step 2: The JSExport Bridge

Step 3: Surgical DOM Mutation in JS

The Performance Payoff

Compile-time Generation with Roslyn

Try it yourself!

UnitBuilds-CC / V.A.L.I.D.

V.A.L.I.D. (Vectorized Asynchronous Logic & Intelligent Diagnostics)

V.A.L.I.D. (Vectorized Asynchronous Logic & Intelligent Diagnostics)

⚡ Performance Benchmarks