Aave Labs lanzó el 8 de septiembre su servidor MCP oficial, con la dirección mcp.aave.com. Los asistentes de IA compatibles con Model Context Protocol pueden leer datos en tiempo real de Aave V3 y V4 a través de una conexión, y también preparar operaciones como depósitos, préstamos, reembolsos, retiros, conmutación de garantías, reclamación de recompensas, liquidaciones e intercambios. La limitación más importante es: las transacciones devueltas por el servidor permanecen sin firmar, la clave privada no la tiene Aave MCP y la autorización final sigue en la cartera del usuario.
Este tipo de interfaz convierte las operaciones DeFi desde botones web a lenguaje natural. Los usuarios pueden preguntar por el factor de salud de una determinada cartera, los rendimientos de stablecoins entre redes, o solicitar que se prepare un depósito de 500 USDC. El asistente no necesita depender de datos de entrenamiento ni de empaquetados de terceros; en su lugar, obtiene tasas, límites, parámetros de riesgo y el estado de las posiciones directamente de las herramientas oficiales. Al mejorar la conveniencia, también hace que los mensajes de error se parezcan más a los activos reales; por eso, el diseño de permisos es más importante que la experiencia de chat.
Los datos oficiales y la construcción de operaciones reducen los errores de integración, pero no eliminan el riesgo de mercado
Lee las herramientas que cubren el encadenamiento de la cobertura, el mercado, las reservas, los tipos de interés, el suministro y los límites de préstamos, además de las series temporales de APY, depósitos y préstamos. La consulta de posiciones puede devolver el suministro en varias cadenas, las deudas, el factor de salud general, las recompensas reclamables y el historial de operaciones. V4 también proporciona datos de salud por cada posición y información de liquidez y contabilidad a nivel de Liquidity Hub, lo que permite al asistente comparar V3, V4 o consultarlos ambos al mismo tiempo.
Las herramientas de transacción no envían directamente la operación por el usuario. La herramienta `prepare_` devuelve una solicitud de transacción o datos tipados de EIP-712, y la wallet del usuario completa la firma. `preview_action` puede simular primero la acción y mostrar el factor de salud después de ejecutarla; el flujo de intercambio también se divide en cotización, preparación, envío y consulta de estado. Esta capa de separación ayuda a comprobar antes de acciones irreversibles, pero el usuario aún debe ver claramente la cadena, los activos, las cantidades, el destinatario de la autorización y el valor mínimo que realmente se recibirá.
Aave dice que el servidor está basado en Aave Kit, por lo que la lógica matemática coincide con la interfaz oficial, y comprime alrededor de 17 KB de detalles de reservas a los campos que necesita el modelo en unos 1 KB. Respuestas más pequeñas ahorran contexto y reducen las oportunidades de que el modelo se equivoque al lidiar con muchos campos irrelevantes. Sin embargo, “con la misma fuente que la interfaz oficial” no garantiza que el precio del mercado no cambie, que el oráculo no se retrase, que la transacción no sea “carraceada” por otro usuario, o que el usuario no malinterprete el lenguaje natural antes de firmar.
La entrada unificada de V3 y V4 también necesita dejar claro la versión. Una misma solicitud de “depositar” o “tomar prestado” puede producir resultados distintos en diferentes redes, mercados y modos de riesgo. Al usar la comparación con all, el asistente debería mostrar la versión y el mercado seleccionados, en lugar de dar solo el APY más alto. Un rendimiento alto puede provenir de un aumento de la utilización o puede ir acompañado de menor liquidez y mayores costes de salida.
Que el usuario controle la firma es solo el mínimo; aún se necesitan simulación, límites y supervisión continua.
Las operaciones no firmadas pueden evitar que el servidor transfiera activos por su cuenta, pero no pueden impedir que el usuario firme una operación incorrecta. La interfaz de la wallet debe traducir la intención en lenguaje natural a un resumen legible, destacando el límite de gasto, las autorizaciones ilimitadas, los activos que se recibirán y los cambios en el factor de salud. Las acciones de alto riesgo pueden requerir una confirmación adicional; las operaciones en lote deben permitir expandirlas elemento por elemento para evitar que el usuario solo vea una frase como “optimizar la posición”.
Los resultados de simulación también tienen límites de tiempo. Se basan en el estado del bloque, los precios y la liquidez de ese momento para estimar; cuando el usuario confirme, las condiciones podrían haber cambiado. El sistema debe mostrar el bloque de simulación, la vigencia de la cotización y el deslizamiento permitido; si es necesario antes de firmar, se debe volver a simular. Si tras recalcular el factor de salud o la cantidad recibida supera los umbrales, se debe detener, no continuar usando resultados antiguos.
En su ejemplo oficial, indican que el agente puede supervisar la posición y preparar el reembolso cuando el factor de salud esté por debajo de 1.5, y luego esperar la firma del usuario. Esto muestra que el diseño actual se parece más a “descubrir automáticamente el riesgo y generar acciones semiautomáticamente” que a una gestión automática sin supervisión. Si el usuario está desconectado, hay congestión de red o los colaterales caen rápidamente, esperar la firma podría no ser suficiente a tiempo. Las instituciones que necesiten automatización deben diseñar además el alcance de la autorización, el servicio de custodia y reglas de emergencia.
El propio conector también debe incluirse en la gestión de seguridad. La empresa debe fijar los dominios oficiales, comprobar TLS, limitar qué herramientas puede invocar el asistente y registrar cada lectura y cada solicitud de preparación. Cualquier texto externo no debería cambiar directamente la dirección de pago ni los parámetros de la transacción. Si el asistente también navega la web, las inyecciones de prompts en la página pueden inducirle a preparar operaciones que no coincidan con la intención del usuario; por eso, las herramientas de transacción deben aislarse del contenido no confiable.
Las consultas de gobernanza también deben distinguir información y votación. MCP puede buscar propuestas, devolver el estado de quórum y enumerar los derechos de voto, pero los resúmenes del modelo podrían omitir condiciones o ventanas de tiempo. Antes de delegar o votar, el usuario aún debe abrir la propuesta original y verificar los datos on-chain, especialmente no autorizar un agente delegado a plazo indefinido basándose en un resumen automático. Un punto de entrada en lenguaje natural es adecuado para reducir la barrera de lectura, pero no debería convertirse en una nueva capa intermedia que oculte detalles del protocolo.
El servidor MCP de Aave ya está en línea y cubre V3 y V4, aunque oficialmente también indican que todavía habrá más funciones en camino. Reduce el coste para los desarrolladores de mantener dos SDK y de implementar dos veces la contabilidad de los protocolos, pero no convierte DeFi en un “banco” de lenguaje natural sin riesgos. La frontera más valiosa es justamente que el servidor no tiene las claves: la IA puede leer, calcular, simular y preparar; las personas deciden si firman o no. Solo cuando esta frontera sea claramente visible en la interfaz, los registros y los permisos, la conveniencia no se obtendrá a costa de perder el control.