kite-lite

kite-lite

mcp-name: io.github.MauricioPerera/kite-lite

Motor web ligero, autocontenido y orientado a agentes. Está diseñado para ejecutarse fuera de Cloudflare en un VPS o contenedor, con un parser HTML, JavaScript aislado, renderizado SVG determinista y una superficie CDP pequeña.

Estado actual

El núcleo DOM en Rust:

• parsea HTML con un parser compatible con HTML5;
• extrae título, texto y enlaces en formato JSON, resolviendo cada enlace relativo a una URL absoluta contra la URL final de la página;
• mantiene una representación de árbol preparada para añadir CSS, JavaScript y renderizado;
• evita estado global en parseo y evaluación local;
• conserva la URL final (post-redirecciones) y el HTML fuente dentro de una sesión CDP;
• mantiene cookies entre navegaciones de una misma sesión (fetch/CDP) mediante un cliente HTTP con cookie jar propio;
• calcula un layout mínimo por elemento ({x, y, width, height} en Element.layout) usando una hoja de estilos por defecto fija por tag (tamaños/negrita de h1-h6, márgenes de p/li/blockquote), con ajuste de texto (word wrap) — ver la sección "Layout mínimo" para las limitaciones; permite click/escritura/submit de formularios por CDP sin ejecutar JS de la página — ver "Interacción: click, escritura y submit de formularios"; renderiza a PNG y PDF además de SVG — ver "Renderizado PNG/PDF"; se puede correr como servidor MCP por stdio — ver "Servidor MCP".

Capacidades para un agente

kite-lite le da a un agente acceso a la web sin arrastrar un navegador real (Chromium/Playwright) — pico de memoria medido de ~4-7 MiB (ver "Recursos mínimos"), arranque en milisegundos, corre bajo --network=none/ --cap-drop=ALL/--read-only sin romperse. Eso cambia el cálculo de costo: en vez de una instancia pesada compartida, es viable levantar una por tarea, en paralelo, en un VPS chico.

Lo que habilita, concretamente:

• Lectura barata de páginas (fetch_page) — resumen liviano (título/texto/links), no el DOM completo con layout. Ahorra contexto frente a devolver HTML crudo cuando el agente solo necesita "qué dice esta página".
• Sesión con estado (browser_navigate + cookies/redirecciones persistentes) — flujos de varios pasos (login → página protegida), mientras el flujo no dependa de JS del lado cliente.
• Interacción de formularios sin ejecutar JS de la página — click, tipeo, submit — como un navegador con JavaScript desactivado (ver "Interacción: click, escritura y submit de formularios"), con selectores por tag, type o name.
• JS aislado y verificable (eval_js) — extraer un valor calculado o probar una expresión, con garantías reales de sandboxing: sin red, sin filesystem, en un proceso separado que ni siquiera puede linkear reqwest/tokio (ver "Servidor MCP").
• Visual barato (render_screenshot/browser_screenshot) — para verificación aproximada o reportes, no para QA visual pixel-perfect (ver "Layout mínimo").
• Auditoría estructurada, no basada en juicio de LLM — los cuatro linters (webmcp-lint, a11y-lint, seo-lint, social-lint) le dan a un agente que construye o revisa sitios un gate determinista y barato, sin gastar una llamada a un modelo para chequear si falta un .
• WebMCP declarativo (browser_call_tool) — si el sitio objetivo publica formularios anotados, el agente consume una interfaz con schema en vez de adivinar selectores (ver "Soporte declarativo de WebMCP").

Los límites duros, por diseño — no son bugs, son la contracara directa de lo anterior (ver "Próximas capas" para el porqué):

• Nada de contenido dependiente de JS del cliente — SPAs, contenido cargado por fetch del lado cliente, cualquier framework que renderiza en el navegador, es invisible.
• Sin interacción real — no corre onclick ni ningún evento de verdad, solo navegación ( ) y submit GET.
• Solo GET en formularios — un method="post" real no se puede enviar con cuerpo.
• Sin multi-pestaña, sin drag&drop, sin upload de archivos, sin scroll infinito.
• No es Playwright — el WebSocket CDP conecta, pero cualquier acción que dependa de Runtime.callFunctionOn contra un DOM vivo (así opera Playwright internamente) no funciona (ver "Compatibilidad CDP").

Tiene sentido para: contenido servido en HTML plano (blogs, docs, la mayoría de sitios de contenido, APIs que devuelven HTML, formularios GET simples), lectura/extracción/auditoría en volumen donde el costo de un navegador real no se justifica, o cualquier caso donde el aislamiento (sin red desde el JS, sin DOM vivo) es una ventaja de seguridad, no una limitación. Para SPAs, interacción compleja, o sitios que validan con JS del cliente, hace falta un navegador real — no hay atajo.

Probarlo

cargo test

cargo run -- https://example.com cargo run -- https://example.com --svg example.svg --js "1 + 2" cargo run -- https://example.com --png example.png cargo run -- https://example.com --pdf example.pdf cargo run -- fetch https://example.com --output page.json cargo run -- eval page.json --js "document.title" cargo run -- render page.json --output page.svg cargo run -- render page.json --output page.png cargo run -- render page.json --output page.pdf cargo run -- serve 127.0.0.1:8787 cargo run -- cdp page.json 127.0.0.1:9222 cargo run -- cdp 127.0.0.1:9222

render (and POST /v1/render, via ?format=png|pdf|svg) picks the output format from the --output path's extension (.svg is the default for anything else).

--js evaluates a script in a fresh Boa JavaScript context with no filesystem, network, or host bindings. The page snapshot exposes document.title, document.body.innerText, and a limited document.querySelector() for the first h1, h2, h3, p, a, or button. --svg writes a deterministic rendering driven by the minimal layout described below (see "Layout mínimo"): every leaf element with text gets word-wrapped and positioned according to a fixed default style per tag.

Example:

cargo run -- https://example.com --js "document.title + ' / ' + document.querySelector('h1').innerText"

The JavaScript context now has source-size, recursion, and VM stack limits. The CLI additionally runs page scripts in a separate kite-lite-js process and terminates it after 1.5 seconds. That evaluator binary does not link reqwest/tokio at all, so it cannot make network requests regardless of what a script tries to do — the isolation is a property of what's compiled into the executable, not just of what the code chooses to call. This is a useful local isolation boundary; production deployments should still add OS-level resource limits and containers or microVMs.

Ejecutar con límites del sistema

La imagen Docker ejecuta el binario como usuario sin privilegios. Para una prueba con límites estrictos de recursos:

docker build -t kite-lite .

docker run --rm --memory=256m --cpus=0.5 --pids-limit=64 --read-only --tmpfs /tmp:rw,noexec,nosuid,size=16m --cap-drop=ALL --security-opt=no-new-privileges kite-lite https://example.com --js "document.title"

El acceso de red es necesario en este modo para descargar la URL. Para páginas ya serializadas, se puede ejecutar el evaluador sin red — y desde que el evaluador (kite-lite-js) es un binario separado que no enlaza reqwest ni tokio, --network=none es una garantía real del binario, no solo de la configuración del contenedor:

docker run --rm --network=none --memory=256m --cpus=0.5 --pids-limit=64 `

--read-only --tmpfs /tmp:rw,noexec,nosuid,size=16m --cap-drop=ALL --security-opt=no-new-privileges -v "${PWD}/page.json:/input/page.json:ro" ` kite-lite eval /input/page.json --js "document.title"

El renderizado también puede ejecutarse sin red:

docker run --rm --network=none --read-only --cap-drop=ALL `

-v "${PWD}/page.json:/input/page.json:ro" -v "${PWD}:/output" kite-lite render /input/page.json --output /output/page.svg

Layout mínimo

fetch, Page.navigate/Page.reload en CDP, y POST /v1/parse calculan un layout de bloque simple sobre el árbol y lo guardan en Element.layout ({x, y, width, height}) antes de devolver el Page. render_svg vuelve a calcularlo internamente al ancho exacto que se le pide renderizar (no reutiliza el guardado en el JSON, para no desalinearse si se pide un ancho distinto).

Esto no es un motor de CSS:

• no hay ni style="..." ni clases/ids — los tamaños, negrita y márgenes son fijos por nombre de tag (h1-h6, p, li, blockquote, strong/b), una imitación mínima de una hoja de estilos de usuario por defecto;
• no hay flujo inline real: cualquier elemento con hijos apila sus hijos verticalmente a ancho completo. Esto es una limitación real del árbol DOM actual, no solo una simplificación: el parser mezcla el texto suelto de un elemento con el texto de sus hijos en un único campo text (sin conservar el orden ni los nodos de texto como hermanos), así que texto suelto junto a un hijo — por ejemplo Hola link — no tiene dónde calcularse por separado una vez que el padre tiene un hijo elemento; solo el texto propio de los nodos hoja se ajusta (word wrap) y se dibuja;
• x siempre es 0.0: no hay eje horizontal en el layout, solo apilado vertical;
• no hay colapso de márgenes ni floats ni posicionamiento.

Renderizado PNG/PDF

render_svg se puede rasterizar a PNG (resvg + tiny-skia, Rust puro, sin depender de un navegador ni de herramientas externas) y ese PNG se puede envolver en un PDF de una sola página (printpdf).

Esto necesita fuentes instaladas en el sistema donde corre el binario: todo lo que dibuja render_svg es texto (no hay rectángulos, imágenes ni otros gráficos), y el rasterizador usa fontdb::load_system_fonts() — no trae ninguna fuente embebida. Sin fuentes, el PNG/PDF sale con el texto faltante (el resto de los elementos, al no existir, tampoco aparece). La imagen Docker instala fonts-dejavu-core para esto; en un build local fuera de Docker, depende de que el sistema operativo tenga alguna fuente disponible.

El PDF no es vectorial: es la imagen PNG rasterizada, envuelta en una página PDF a 96 DPI — no hay texto seleccionable ni buscable. Un PDF vectorial de verdad necesitaría su propio pipeline de fuentes independiente del rasterizado (printpdf trae soporte nativo de SVG, pero internamente usa una versión vieja de usvg con Options::default() sin fuentes cargadas y sin forma de inyectar una — no es viable para texto).

Control API local

El servidor se enlaza a loopback por defecto y expone:

• GET /health
• POST /v1/parse con HTML en el body (los enlaces quedan relativos, ya que este endpoint no recibe una URL base para resolverlos);
• POST /v1/render con un snapshot JSON — ?format=svg (default), png o pdf;
• POST /v1/eval con { "page": ..., "script": "..." }.

No se debe publicar directamente a Internet; colócalo detrás de autenticación y un proxy si se necesita acceso remoto.

CDP experimental

El modo cdp abre un WebSocket compatible con una parte pequeña del Chrome DevTools Protocol:

• Browser.getVersion;
• Runtime.enable, Page.enable, Network.enable, DOM.enable;
• Runtime.evaluate;
• Page.getNavigationHistory, Page.getResourceTree;
• Page.navigate, Page.reload, Page.captureSnapshot;
• DOM.getDocument, DOM.querySelector, DOM.querySelectorAll;
• DOM.getOuterHTML, DOM.getAttributes, DOM.getBoxModel;
• Input.dispatchMouseEvent, Input.dispatchKeyEvent;
• Target.getTargets, Target.getTargetInfo, Target.attachToTarget, `Target.attachToBrowserTarg