kite-lite MCP server

kite-lite

<!-- m8ven-verify: 65c4feb01b6a9e62bbf352731130f73f -->

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:

relativo a una URL absoluta contra la URL final de la página;

• parsea HTML con un parser compatible con HTML5;
• extrae título, texto y enlaces en formato JSON, resolviendo cada enlace

mediante un cliente HTTP con cookie jar propio;

• 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)

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".

• calcula un layout mínimo por elemento ({x, y, width, height} en

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:

(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".

• Lectura barata de páginas (fetch_page) — resumen liviano

persistentes) — flujos de varios pasos (login → página protegida), mientras el flujo no dependa de JS del lado cliente.

• Sesión con estado (browser_navigate + cookies/redirecciones

tipeo, submit — como un navegador con JavaScript desactivado (ver "Interacción: click, escritura y submit de formularios"), con selectores por tag, type o name.

• Interacción de formularios sin ejecutar JS de la página — click,

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").

• JS aislado y verificable (eval_js) — extraer un valor calculado o

verificación aproximada o reportes, no para QA visual pixel-perfect (ver "Layout mínimo").

• Visual barato (renderscreenshot/browserscreenshot) — para

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 .

• Auditoría estructurada, no basada en juicio de LLM — los cuatro

publica formularios anotados, el agente consume una interfaz con schema en vez de adivinar selectores (ver "Soporte declarativo de WebMCP").

• WebMCP declarativo (browsercalltool) — si el sitio objetivo

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

Shortened. The full README is on GitHub.