Estaba observando a un agente de IA intentar añadir un artículo a un carrito de compras. No cualquier carrito — un sitio de e-commerce real que yo mismo había construido, así que conocía cada elemento, cada animación, cada caso límite. El agente tenía capacidades de visión, un modelo sólido detrás, y yo había dedicado la mejor parte de un martes a configurarlo correctamente.
¿El resultado? El agente tomó una captura de pantalla, identificó mal un menú desplegable, hizo clic en el elemento equivocado tres veces, actualizó la página por accidente, y finalmente me envió un educado mensaje de error explicando que no podía completar la tarea.
47 segundos. Más en tokens de API de lo que me gustaría admitir. Cero tareas completadas.
Ese momento cristalizó algo que venía percibiendo desde hacía tiempo: la navegación web con IA basada en visión es poderosa en demos controladas y genuinamente dolorosa a escala de producción. El modelo ve píxeles. Adivina coordenadas. Hace clic donde cree que está un botón, no donde realmente está. En una página de marketing estática con botones grandes y coloridos, funciona bien. En cualquier cosa con UI dinámica, estados hover, modales que aparecen con animación, o elementos de menú que solo se muestran al interactuar — falla, lenta y costosamente.
Así que cuando escuché que Google Chrome estaba lanzando algo llamado WebMCP en Chrome Beta, lo archivé como "interesante pero probablemente no está listo." Dos semanas después tenía el flag activado y estaba observando interacciones de agentes de IA que se completaban en menos de dos segundos con una fiabilidad casi perfecta.
Me equivoqué con la parte de "no está listo." Aquí está todo lo que he aprendido.
Los dos enfoques fallidos de la navegación web con IA
Antes de que WebMCP tenga sentido, necesitas entender por qué las opciones actuales no son suficientemente buenas para trabajo serio.
La navegación basada en visión es el enfoque en el que la mayoría de la gente piensa cuando imagina agentes de IA interactuando con sitios web. El agente captura una captura de pantalla, la envía a un modelo de visión, el modelo identifica elementos de la UI, y luego el agente intenta hacer clic, desplazarse o escribir basándose en esa interpretación visual. Herramientas como Computer Use de Claude, las capacidades visuales de GPT-4o, y varios frameworks de automatización de navegadores usan variaciones de este enfoque.
Los problemas se acumulan a medida que aumenta la complejidad. Los menús desplegables activados por hover requieren que el agente primero haga hover, tome otra captura de pantalla y luego haga clic — y frecuentemente se equivoca en la posición del hover. Las transiciones animadas confunden el timing de las capturas. Los elementos superpuestos causan clics erróneos. El modo oscuro, configuraciones de alto contraste, o cualquier CSS que difiera de los datos de entrenamiento degrada el rendimiento notablemente.
El problema de costos es real y a menudo se subestima. La inferencia de modelos de visión es cara en relación con la inferencia de texto. Cuando ejecutas un flujo de trabajo que requiere 20-30 interacciones de UI, los costos en tokens por procesamiento de visión se acumulan rápido. Ejecuté una automatización de varios pasos en una UI de dashboard compleja — 24 interacciones discretas — y los costos del modelo de visión por sí solos superaron lo que normalmente gasto en un día entero de trabajo con IA basada en texto.
Los servidores MCP personalizados — la segunda opción — resuelven los problemas de fiabilidad y costo de manera elegante, pero introducen un conjunto diferente de limitaciones. Model Context Protocol se ha convertido en el estándar para dar a los agentes de IA acceso a herramientas externas y APIs. Construyes un servidor personalizado que expone la funcionalidad de tu aplicación como herramientas invocables, y el agente llama directamente a esas herramientas en lugar de intentar hacer clic en botones en una pantalla.
El problema: los servidores MCP requieren preconfiguración manual. Antes de que comience una sesión de agente, necesitas saber qué servidores MCP va a necesitar el agente, instalarlos, configurar los parámetros de conexión y mantener esas configuraciones actualizadas. No hay descubrimiento dinámico — el agente no puede llegar a un sitio web arbitrario y preguntar "¿qué puedo hacer aquí?" Solo puede usar herramientas que fueron registradas antes de que comenzara la sesión.
Esta es una limitación arquitectónica fundamental. Significa que los servidores MCP escalan bien para integraciones conocidas y estables — las APIs internas de tu empresa, herramientas estándar de desarrollo — pero no funcionan para la web abierta donde podrías navegar a cualquiera de miles de sitios.
WebMCP es el intento de tomar lo que funciona de MCP (llamadas directas a funciones, entradas tipadas, ejecución fiable) y llevarlo al navegador con descubrimiento dinámico. Y la combinación es más poderosa que cualquiera de los dos enfoques por separado.
Qué es realmente WebMCP — más allá de la descripción de marketing
Aquí está el panorama técnico preciso, porque los resúmenes de alto nivel que he leído pasan por alto lo que hace esto interesante.
WebMCP es un estándar de JavaScript construido para entornos de navegador. Un sitio web puede registrar un conjunto de funciones de herramientas invocables usando la API de WebMCP — cada herramienta tiene un nombre, una descripción en lenguaje natural, un esquema de entrada en formato JSON Schema, y una función ejecutora que contiene la implementación real. Cuando un agente de IA (en cualquiera de sus formas: barra lateral del navegador, aplicación de escritorio, extensión de IDE) navega a una página con herramientas WebMCP registradas, puede consultar la interfaz WebMCP para descubrir qué está disponible.
No se requiere pre-registro. No hay archivos de configuración. No hay paso de instalación para el usuario final.
El modelo mental que me hizo entender: WebMCP hace que los sitios web sean "legibles para agentes." Ahora mismo, los sitios web están diseñados para ojos humanos y clics de ratón. WebMCP añade una interfaz paralela diseñada para agentes de IA — una que habla en funciones y esquemas en lugar de píxeles y coordenadas.
Considera un ejemplo concreto. Tienes una aplicación de tareas pendientes. Normalmente, un humano interactúa con ella haciendo clic en botones con la etiqueta "Añadir Tarea", escribiendo en un campo de entrada, presionando Enter. Un agente de IA usando navegación basada en visión tiene que simular todos esos pasos. Un agente de IA usando WebMCP puede llamar a addTodo({ text: "buy eggs", priority: "medium" }) y recibir { success: true, id: "task_847" } en menos de 200 milisegundos.
La diferencia en la calidad de interacción no es incremental. Es categórica.
Lo que me hizo prestar más atención a WebMCP específicamente — frente a otros experimentos de automatización de navegadores que he visto — es el soporte multi-agente incorporado en el diseño. Los mismos registros de herramientas WebMCP en una página pueden ser accedidos por un agente en la barra lateral de Chrome, Claude Desktop ejecutándose localmente, Cursor o VS Code con una extensión de agente, o una herramienta de IA personalizada que tú mismo hayas construido. El sitio web expone la API una vez. Cualquier agente compatible se beneficia sin que el sitio web necesite saber de antemano qué agentes se conectarán.
Esto es significativamente diferente del modelo de servidor MCP personalizado, que crea conexiones punto a punto entre agentes específicos y servicios específicos. WebMCP es difusión: registra tus herramientas, y cualquier agente compatible con WebMCP que navegue allí puede usarlas.
Pero aquí está la parte que hace esto viable para aplicaciones reales en lugar de solo demos de juguete — y es la parte que la mayoría de la cobertura temprana omite por completo.
El problema de autenticación que tenía que resolverse
Una aplicación de tareas sin cuentas, sin datos privados y con cuatro herramientas es una demo limpia. El software real no funciona así.
Las aplicaciones reales tienen cuentas de usuario. Las cuentas de usuario tienen datos privados que pertenecen a personas específicas. Si expones herramientas WebMCP sin autenticación, estás exponiendo los datos de cada usuario a cualquier agente que navegue a tu página. Eso no es un compromiso que puedas llevar a producción. Es una brecha de seguridad esperando a ocurrir.
Cuando miré WebMCP por primera vez, esta fue mi pregunta inmediata: ¿cómo funciona la autenticación? Porque "añadimos una API de JavaScript que permite a los agentes de IA llamar a las funciones de tu sitio web" suena genial hasta que piensas en cuáles podrían ser esas funciones para un usuario autenticado. ¿Puede cualquier agente leer mis correos? ¿Enviar pedidos en mi nombre? ¿Acceder a mis datos financieros?
La respuesta — cuando se implementa correctamente — es no. Y entender por qué requiere comprender la integración con OAuth 2.1 que soporta WebMCP.
WebMCP incluye una capa de autenticación construida sobre OAuth 2.1 — el mismo framework de autorización estándar de la industria usado por Google, GitHub, Stripe, y esencialmente todos los servicios web serios. Cuando un agente de IA intenta llamar a una herramienta WebMCP protegida, es redirigido a través de un flujo de autorización OAuth. El usuario otorga explícitamente al agente permisos específicos (scopes), recibe un token con alcance limitado exactamente a esos permisos, y el agente usa ese token para llamadas posteriores. La renovación de tokens, expiración y revocación funcionan según la especificación de OAuth 2.1.
La implementación que probé usaba la infraestructura OAuth de Scale Kit, y aquí doy crédito donde es debido: la integración de Scale Kit está cuidadosamente diseñada. Configurarla requiere tres cosas — una URL de entorno, un client ID y secret, y un resource ID. Eso es genuinamente todo. Todo lo demás — almacenamiento de tokens, ciclos de renovación, aplicación de scopes, gestión de sesiones de usuario — se ejecuta dentro de la infraestructura de Scale Kit.
Para cualquiera que haya implementado OAuth desde cero y tenga las cicatrices de batalla para demostrarlo, tener una integración OAuth multi-tenant funcional que no necesitas mantener tú mismo no es poca cosa.
El aspecto multi-tenant importa más de lo que la gente enfatiza. Múltiples usuarios, cada uno con su propia sesión autenticada, cada uno con su propio token con alcance limitado a sus propios datos, todos potencialmente ejecutando agentes de IA simultáneamente contra la misma aplicación habilitada con WebMCP. Scale Kit maneja esa complejidad. Tus funciones ejecutoras de WebMCP reciben un authContext validado que te dice quién está haciendo la solicitud — simplemente lo usas.
Lo que creo que esto desbloquea, en términos prácticos: una clase de integraciones de agentes de IA que previamente estaban bloqueadas detrás de un esfuerzo de implementación significativo. "Construye un agente que pueda gestionar las tareas de mi proyecto" requiere que el agente lea datos privados del proyecto, haga llamadas API autenticadas, maneje acceso multiusuario — todas cosas que ahora son mucho más abordables si construyes sobre WebMCP + Scale Kit OAuth en lugar de intentar implementar la autenticación desde cero.
Configurando esto: qué funciona realmente (y qué no)
Voy a ser específico aquí porque la documentación todavía está poniéndose al día con la implementación, y me encontré con varios problemas que no están cubiertos en ningún lugar que encontré.
Obteniendo Chrome Beta con WebMCP habilitado
WebMCP es experimental a fecha de febrero de 2026. Necesitas Chrome Beta — no Chrome Stable, no Chrome Canary, específicamente Beta. Descárgalo desde el canal de lanzamiento Beta de Google e instálalo por separado de tu instalación regular de Chrome.
Una vez instalado, navega a chrome://flags en Chrome Beta y busca "WebMCP." Activa el flag. Reinicia Chrome Beta. Este paso es fácil de pasar por alto porque la función simplemente no existe en la UI sin el flag — no verás ningún error, simplemente no funcionará.
La extensión Model Context Tool Inspector
La extensión de Chrome actúa como puente entre la API JavaScript de WebMCP en la página y tu agente de IA. Instálala en Chrome Beta específicamente. Las extensiones no se transfieren automáticamente entre tu Chrome regular y Chrome Beta — necesitas instalarla de nuevo en Beta.
Un problema que me encontré: si instalas la extensión mientras Chrome Beta se ejecuta sin el flag de WebMCP habilitado, la extensión se instala pero no inicializa completamente el puente WebMCP. Activa el flag primero, reinicia, y luego instala la extensión.
Registrando herramientas en tu aplicación
Este es el trabajo orientado al desarrollador. Añadir WebMCP a una aplicación existente significa registrar tus herramientas usando la API de JavaScript. Así es como se ve un registro realista:
// Call this when your app initializes
function registerWebMCPTools() {
// The optional chaining means this silently does nothing
// in browsers that don't support WebMCP — no errors,
// no broken UI for users without the extension.
window.webmcp?.registerTool({
name: "addTask",
description: "Creates a new task in the user's task list. " +
"Use this when the user wants to add, create, or save a new task. " +
"Returns the new task's ID on success.",
inputSchema: {
type: "object",
properties: {
title: {
type: "string",
description: "The task title or description"
},
dueDate: {
type: "string",
format: "date",
description: "Optional due date in YYYY-MM-DD format"
},
priority: {
type: "string",
enum: ["low", "medium", "high"],
description: "Task priority level"
}
},
required: ["title"]
},
executor: async (params) => {
const task = await taskService.create({
title: params.title,
dueDate: params.dueDate || null,
priority: params.priority || "medium"
});
return { success: true, taskId: task.id, title: task.title };
}
});
window.webmcp?.registerTool({
name: "listTasks",
description: "Retrieves the user's current task list. " +
"Use this to show, view, or check existing tasks. " +
"Can filter by status (pending, completed, or all).",
inputSchema: {
type: "object",
properties: {
status: {
type: "string",
enum: ["pending", "completed", "all"],
description: "Filter tasks by completion status"
}
}
},
executor: async (params) => {
const tasks = await taskService.list(params.status || "all");
return { tasks: tasks.map(t => ({
id: t.id,
title: t.title,
status: t.completed ? "completed" : "pending",
dueDate: t.dueDate
}))};
}
});
}
El campo description está haciendo más trabajo del que parece. Esta descripción en lenguaje natural es lo que el modelo de IA lee para entender cuándo llamar a cada herramienta y cómo mapear la intención del usuario a la función correcta. Dediqué más tiempo a escribir descripciones claras de herramientas que a cualquier otra parte de la implementación, y valió cada minuto.
Descripciones vagas como "Gestiona tareas" llevan al modelo a tomar decisiones incorrectas. Descripciones específicas como "Crea una nueva tarea — usa esto cuando el usuario quiera añadir, crear o programar algo nuevo" le dan al modelo lo que necesita para enrutar las solicitudes correctamente.
Añadiendo autenticación para aplicaciones reales
Para cualquier cosa con datos de usuario, querrás herramientas protegidas detrás de autenticación:
window.webmcp?.registerTool({
name: "getMyProjects",
description: "Retrieves all projects belonging to the authenticated user. " +
"Requires the user to be logged in. Returns project names, statuses, " +
"and team member counts.",
requiresAuth: true,
scopes: ["projects:read"],
inputSchema: {
type: "object",
properties: {
includeArchived: {
type: "boolean",
description: "Whether to include archived projects (default: false)"
}
}
},
executor: async (params, authContext) => {
// authContext is injected by the WebMCP runtime after token validation.
// You don't need to validate the token yourself — it's already done.
const projects = await projectService.getUserProjects(
authContext.userId,
{ includeArchived: params.includeArchived || false }
);
return { projects };
}
});
El authContext.userId es poblado por el runtime de WebMCP después de que el token OAuth es validado. Tu código ejecutor simplemente lo usa — no estás haciendo verificación de tokens, parsing de tokens ni extracción de IDs de usuario tú mismo. Eso ya ocurrió antes de que tu función se ejecute.
Conectando Claude Desktop (u otro agente)
La configuración del agente depende de qué agente estés usando. Para Claude Desktop, hay una entrada de conexión WebMCP que añades al archivo de configuración de Claude Desktop. Para agentes basados en navegador que usan la extensión de Chrome, el descubrimiento es automático una vez que la extensión está instalada en Chrome Beta con el flag habilitado.
El problema más común: Claude Desktop no muestra herramientas WebMCP. Primera verificación — ¿está Chrome Beta ejecutándose (no solo instalado)? La extensión necesita una instancia de Chrome Beta en ejecución para comunicarse. Segunda verificación — ¿la página tiene herramientas registradas? Abre la consola de tu navegador y ejecuta window.webmcp?.listTools() para verificar que las herramientas están realmente registradas en la página.
Si las herramientas aparecen en la consola pero no en Claude Desktop, el puente entre Chrome Beta y Claude Desktop no se está conectando. Reinicia Claude Desktop con Chrome Beta ya abierto, no al revés.
Lo que realmente pienso — sin discurso de marketing
Bien. Es hora de ser honesto sobre dónde creo que realmente se encuentra WebMCP, porque la cobertura de la prensa tecnológica ha sido un poco demasiado uniformemente positiva.
La idea técnica central es sólida. Pasar del análisis de UI basado en visión a la invocación directa de funciones es categóricamente mejor — más rápido, más barato, más fiable. No discuto eso. Mi interacción fallida de 47 segundos con el carrito de compras versus las llamadas de herramientas WebMCP de menos de 2 segundos no son números seleccionados a conveniencia; son representativos de lo que veo consistentemente.
Mi preocupación es la velocidad de adopción, y no es técnica — es económica.
WebMCP solo funciona si los sitios web lo implementan. Cada sitio web que no lo implementa permanece en territorio de "navegación basada en visión" para los agentes de IA. E implementar WebMCP requiere tiempo de desarrollo. Necesitas identificar qué acciones de usuario exponer como herramientas, escribir las definiciones de herramientas, escribir las funciones ejecutoras, probar el flujo de autenticación, y actualizar todo cuando tus APIs subyacentes cambien. Para una startup construyendo un producto nuevo con mentalidad AI-first, esto podría ser lo mínimo indispensable. Para una empresa establecida con un backlog de producto completo y recursos de ingeniería limitados — esto compite con funcionalidades que los clientes están solicitando activamente hoy.
La analogía con RSS sigue viniendo a mi mente. RSS era técnicamente superior a revisar manualmente los sitios web en busca de actualizaciones. Tardó una década en ver una adopción significativa, requirió que Google Reader se volviera dominante en su espacio, y luego colapsó cuando Google Reader cerró. Que la tecnología correcta gane no está garantizado, y no es rápido.
También quiero ser directo sobre la situación de estabilidad de la especificación. WebMCP es experimental. El flag de Chrome te lo advierte. Este artículo describe la implementación a fecha de febrero de 2026 — nombres de métodos específicos, formatos de parámetros y flujos de autenticación pueden cambiar antes de que WebMCP se lance en Chrome estable. He visto otras APIs experimentales de navegador pasar por múltiples revisiones con cambios incompatibles antes de estabilizarse. Construye algo con WebMCP hoy sabiendo que probablemente necesitarás actualizarlo cuando la especificación evolucione.
Una admisión honesta: inicialmente descarté el enfoque declarativo HTML mencionado en parte de la documentación de WebMCP. Asumí que el registro solo con JavaScript era la opción obviamente correcta. Después de pensarlo más, entiendo por qué una opción declarativa podría ser útil para sitios de contenido estático o aplicaciones renderizadas en servidor donde el JavaScript del lado del cliente es mínimo. Todavía no estoy completamente convencido de que sea necesario, pero fui demasiado rápido en descartarlo.
Aquí está la parte en la que quiero rebatir específicamente: el encuadre de WebMCP como "reemplazo" de los servidores MCP tradicionales es incorrecto, y está causando confusión.
Los servidores MCP tradicionales siguen siendo la herramienta correcta para cualquier cosa que no sea interacción navegador-sitio web. Acceso a APIs del backend, consultas a bases de datos, operaciones del sistema de archivos, lanzar procesos — nada de eso pasa por un navegador. Los servidores MCP personalizados lo manejan bien, y WebMCP no toca esos casos de uso en absoluto.
La imagen real: los agentes de IA usarán ambos. Servidores MCP personalizados para capacidades de backend, WebMCP para interacciones con sitios web basadas en navegador. Son complementarios, no competidores.
Lo que puedes esperar de forma realista
Para cualquiera que esté evaluando si vale la pena integrar WebMCP ahora, aquí está la versión honesta de lo que puedes esperar.
Las ganancias de velocidad son reales y significativas. Llamadas a herramientas de menos de 2 segundos versus interacciones basadas en visión de 35-50 segundos es una mejora de productividad genuina para cualquier flujo de trabajo donde un humano está esperando el resultado. Si estás construyendo funcionalidades de agentes de IA orientadas al usuario, esta diferencia importa a tus usuarios.
Las mejoras de costo son significativas a escala. La inferencia de modelos de visión cuesta más por operación que la inferencia basada en llamadas a funciones. Para flujos de trabajo con muchas interacciones, la diferencia se acumula. No he ejecutado benchmarks formales en suficientes escenarios para darte una ratio de costos fiable, pero en mis pruebas, cambiar de interacciones basadas en visión a interacciones basadas en WebMCP redujo los costos del modelo aproximadamente entre un 60-75% para tareas equivalentes.
La fiabilidad mejora drásticamente. Mi seguimiento informal de tasas de éxito mostró un 97-98% de éxito en llamadas a herramientas WebMCP correctamente formadas versus aproximadamente un 68-72% en interacciones equivalentes basadas en visión. Los fallos en el modo basado en visión fueron variados — elemento incorrecto identificado, problemas de timing con animaciones, estado inesperado de la UI. Los fallos de WebMCP fueron casi exclusivamente entradas mal formadas (que se solucionan mejorando los esquemas de herramientas) o errores del ejecutor (que son simplemente bugs normales en tu código, fáciles de depurar).
La autenticación funciona si la configuras correctamente. Una vez que Scale Kit OAuth estuvo correctamente configurado en mi entorno de pruebas, tuve cero fallos de autenticación durante pruebas extensas. La renovación de tokens ocurrió de forma transparente. Cambiar entre múltiples cuentas de usuario de prueba funcionó correctamente cada vez.
Lo que estás intercambiando: tiempo de implementación por adelantado. Añadir WebMCP a una aplicación existente toma unas pocas horas para conjuntos de herramientas simples, potencialmente uno o dos días si también estás configurando OAuth y soporte multiusuario. También estás aceptando el riesgo de inestabilidad de la especificación hasta que WebMCP se lance en Chrome estable.
El consejo realista: si estás construyendo un nuevo producto orientado a IA desde cero, implementa WebMCP desde el primer día. La sobrecarga es baja cuando construyes desde cero. Si estás evaluando si añadir WebMCP a una aplicación de producción existente, empieza con tus acciones de usuario de mayor valor — aquellas de las que un agente de IA se beneficiaría más — e implementa esas primero. Observa la diferencia de calidad antes de comprometerte con una integración completa.
Hacia dónde va esto
El día que logré que funcionara la integración OAuth, pasé unos minutos pensando en un hipotético específico: ¿qué significaría si cada sitio web expusiera su funcionalidad principal como herramientas WebMCP?
No todo — eso es poco realista y probablemente indeseable. Pero las interacciones de alto valor. Las acciones que los usuarios realizan repetidamente. Los flujos de trabajo que importan.
Navegas a tu herramienta de gestión de proyectos y tu asistente de IA puede leer tu lista de tareas, marcar elementos como completados, añadir nuevas tareas y actualizar prioridades — todo sin tomar una sola captura de pantalla.
Navegas a tu banco y tu asistente de IA puede consultar tu saldo, revisar transacciones recientes o iniciar una transferencia — autenticado, con alcance limitado, revocable en cualquier momento.
Navegas a tu sitio de reserva de viajes y tu asistente de IA puede buscar vuelos, comparar precios y reservar — directamente, sin pelear con una UI dinámica.
Estos no son escenarios de un futuro lejano. Son lo que WebMCP está diseñado para hacer posible, y son técnicamente alcanzables hoy para desarrolladores dispuestos a implementar la integración.
La brecha entre "técnicamente alcanzable" y "ampliamente disponible" es la adopción. Estamos al comienzo de esa curva de adopción ahora mismo — Chrome Beta, flags experimentales, documentación temprana para desarrolladores. Si WebMCP alcanza masa crítica o permanece como un estándar de nicho depende de cosas que no son puramente técnicas: herramientas para desarrolladores, expansión del soporte en navegadores, crecimiento del ecosistema de agentes de IA, y si suficientes sitios web de alto valor consideran que la integración vale el esfuerzo.
Mi apuesta es que alcanza masa crítica, pero más lento de lo que sugiere el hype inicial. El problema subyacente — los agentes de IA necesitando interactuar con sitios web de forma eficiente — es real y persistente. La solución técnica que WebMCP proporciona es claramente mejor que las alternativas. Esos dos hechos eventualmente se encuentran.
La pregunta que vale la pena considerar: si alguien con un agente compatible con WebMCP navega a tu aplicación hoy — ¿puede lograr algo útil? ¿O sigue atascado viendo a un modelo de visión identificar mal tu menú hover durante 47 segundos?
Esa es la brecha que WebMCP está diseñado para cerrar. Construir algo para cerrarla para tus usuarios vale el fin de semana.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (builds e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
