Seis herramientas MCP, y lo que los adaptadores desbloquean después (ahora 17)
Cualquier modelo que hable MCP puede dirigir el runtime, sin integración personalizada por proveedor. El contrato de seis herramientas de RakuAI es la frontera que hace real un runtime de autoridad determinista, y el punto de inflexión donde se convierte en infraestructura sobre la que otros construyen.
El runtime lleva hablando Model Context Protocol desde finales de marzo. El commit que lo puso en producción es 138b538b, “feat(mcp): reframe MCP server from game-agent control to world model runtime orchestration”. El cambio de enfoque en ese mensaje de commit es la sustancia de este artículo, y el siguiente paso sobre él es lo que quiero dejar por escrito.
Cómo se ve MCP en el runtime hoy
Seis herramientas, en un servidor Python en src/mcp/raku_mcp_server.py, transporte sobre stdio, namespace raku.*. Permisos de denegación por defecto aplicados por herramienta y por invocador. Cada llamada queda registrada en un log de auditoría.
Las seis herramientas:
load_world_model(adapter_name, config)registra un backend de modelo de mundo. Hoy los nombres de adaptador son marcadores de posición:VideoPredictor-v2,NeuralRadianceField,PhysicsFoundation. Mañana serán adaptadores reales.ingest_frame(adapter_name, frame_data, frame_index, timestamp)entrega un fotograma de un modelo generativo al grafo de escena del runtime.get_scene_state(include_physics, include_transforms)es la instantánea de solo lectura del mundo. Segura en todos los modos.set_render_target(target_type, config)configura dónde se renderiza el mundo: WebGL, visor de VR, ventana nativa, fuera de pantalla.start_simulation(tick_rate, max_duration, realtime)inicia el bucle de simulación. Solo en sandbox y desarrollo. Los servidores de producción rechazan esta llamada.get_metrics()devuelve una instantánea de rendimiento. FPS, tiempo de fotograma, número de nodos, carga del adaptador, tiempo de actividad. Segura en todos los modos.
Las herramientas de solo lectura funcionan en cualquier entorno. Las herramientas que mutan (load, ingest, set, start) funcionan solo en sandbox y desarrollo. La postura de producción es “los agentes externos pueden preguntar, no ordenar”. Esa postura se aplica en el servidor, no en el invocador. Un socio que se comporte mal no puede mutar por accidente un modelo de mundo de producción.
Por qué estas seis y no otra cosa
La primera versión del servidor MCP, antes de marzo, exponía herramientas de agente de juego: move_npc, set_dialog, place_object, query_inventory. Esas son las herramientas equivocadas para la frontera. Son asuntos de nivel de aplicación, no de nivel de motor. Convierten al motor en algo dentro de lo que el agente mete la mano. Se supone que el motor es aquello sobre lo que el agente se ejecuta.
El replanteamiento en el PR #1311 cambió la superficie de herramientas. Las nuevas herramientas operan sobre abstracciones de modelo de mundo: cargar un backend, empujar un fotograma, consultar el estado, configurar el renderizado, iniciar la simulación, leer métricas. Un agente que quiere mover a un NPC lo hace empujando un fotograma a través del adaptador de modelo de mundo, no llamando a move_npc sobre el motor. El motor sigue siendo la autoridad sobre física, colisiones, puntuación, estado multijugador. El modelo de mundo es un colaborador, no un controlador.
Esa distinción es lo que permite que el motor sea agnóstico respecto a qué modelo de mundo hay al otro lado. Genie, Runway, Sora antes de que cerrara, un modelo propio interno, un modelo de fundación física, un renderizador experimental de campos de radiancia neuronal. Todos hablan la misma superficie de seis herramientas. Ninguno puede anular la autoridad del motor sobre lo que realmente está ocurriendo en la simulación.
Esto es lo que significa en la práctica “runtime de autoridad determinista”. Usamos mucho esa frase en conversaciones con socios. La superficie MCP es lo que la hace cierta.
La brecha entre hoy y lo que viene después
La versión honesta de dónde está MCP: el servidor es real, la capa de seguridad está endurecida, los esquemas están tipados, el registro de auditoría funciona y los adaptadores son stubs.
Esa última palabra es el peso de este sábado. Las seis herramientas aceptan una cadena adapter_name. Los adaptadores stub (VideoPredictor-v2, NeuralRadianceField, PhysicsFoundation) son marcadores de posición que demuestran la ruta de despacho. Hay archivos de andamiaje en src/environment/ para VeoEnvironmentAdapter y RunwayEnvironmentAdapter que aún no están conectados a un modelo real.
El siguiente paso es un adaptador, de extremo a extremo, con un modelo real de un socio al otro lado. El candidato que sigue apareciendo en las conversaciones de GDC es un predictor de video (Runway, o un modelo abierto más pequeño) que alimenta datos de fotogramas de escena a través de ingest_frame mientras el motor gestiona física y colisiones por debajo. Una demo donde lo visual sale de un modelo generativo y la jugabilidad sale del motor, y ninguno de los dos lados tiene que saber del otro salvo a través de la frontera MCP.
Si esa demo funciona, todos los demás adaptadores tienen una forma conocida. La parte difícil no es la integración. La parte difícil es el contrato. El contrato son las seis herramientas.
Qué significa esto para los socios
Dos cosas concretas, ambas dignas de decirse en voz alta.
Cualquier agente que hable MCP puede dirigir el runtime. Un laboratorio de modelos que quiera probar su generación contra un motor real no necesita una integración personalizada. Escribe un cliente MCP, llama a load_world_model con su backend, empuja fotogramas con ingest_frame, lee el estado de la escena con get_scene_state. El motor hace el resto. El socio obtiene una superficie de evaluación real para su modelo. Nosotros obtenemos una demostración real de que el motor es agnóstico de proveedor.
Cualquier desarrollador que construya herramientas sobre el runtime puede usar la misma superficie. El servidor MCP no es una API exclusiva para socios. Es la API. Un estudio que construye una herramienta de autoría, un investigador que ejecuta evaluaciones por lotes, un socio de hardware que integra un nuevo sensor, todos obtienen las mismas seis herramientas. No hay una API “interna” separada escondida detrás de la pública. Está la superficie MCP y está la API en C que usa el SDK, y eso es toda la cara pública del runtime.
El endurecimiento que aún falta
Tres piezas de trabajo que quiero dejar por escrito para que se hagan:
Arnés de despliegue de producción. El servidor MCP hoy se instancia en pruebas. Necesita una plantilla de servicio: configuración por variables de entorno para modo, tokens de autenticación y límites de tasa, un endpoint de comprobación de salud, apagado ordenado, empaquetado en contenedor. Higiene operativa estándar. Nada glamoroso. Lo que convierte un servidor que funciona en uno desplegable.
Failover multi-proveedor. Cuando el adaptador principal es lento o no está disponible, el servidor debería poder enrutar a uno secundario. El documento de estrategia lleva un tiempo hablando de esto. La implementación no ha llegado. La forma es sencilla. Las pruebas serán el trabajo.
Programa de recompensas para adaptadores. Una vez que un adaptador funcione de extremo a extremo y el contrato esté probado, el movimiento correcto es publicar el contrato del adaptador e invitar al ecosistema a escribir más. Un adaptador de Genie de alguien que conozca Genie. Un adaptador de Marble de alguien que conozca Marble. Un adaptador de modelo personalizado de un grupo de investigación. Nuestro trabajo deja de ser “integrar cada modelo” y pasa a ser “publicar el contrato y revisar las implementaciones”.
Ese último movimiento es el que más me entusiasma. Es el punto de inflexión donde MCP deja de ser una herramienta que construimos para nuestro propio uso y empieza a ser infraestructura sobre la que otros construyen.
La semana que viene
La cola que estoy registrando este sábado por la mañana tiene el primer adaptador real. Alcance específico, objetivo estrecho, demo funcionando para fin de mes si sale bien. Si no sale bien, aprendemos qué nos equivocamos sobre el contrato mientras todavía es barato cambiarlo.
Si estás en un laboratorio de modelos y tienes una opinión sobre cómo deberían verse las fronteras al estilo MCP para runtimes que hablan con modelos generativos, esta es la semana correcta para compartirla. El contrato aún no está cerrado. Los comentarios cuestan menos ahora de lo que costarán dentro de un trimestre.
Seis herramientas, desplegadas, auditadas, tipadas por esquema, denegación por defecto. Adaptadores a continuación. La frontera es real. El trabajo que se ejecuta sobre ella es lo que viene después.
Sábado en movimiento.
Dirige un motor real a través de un único contrato MCP
Si tu modelo habla Model Context Protocol, puede orquestar un runtime espacial de producción: agnóstico de proveedor, denegación por defecto, cada llamada auditada. El contrato está abierto a comentarios mientras todavía es barato darle forma.