Seis Ferramentas MCP, e o Que os Adaptadores Vão Destravar em Seguida (agora 17)
Qualquer modelo que fale MCP pode conduzir o runtime — sem integração personalizada por fornecedor. O contrato de seis ferramentas da RakuAI é a fronteira que torna real um runtime de autoridade determinística, e o ponto de inflexão em que ele se torna infraestrutura sobre a qual outros constroem.
O runtime fala Model Context Protocol desde o fim de março. O commit que entregou isso é 138b538b, “feat(mcp): reframe MCP server from game-agent control to world model runtime orchestration.” A mudança de enquadramento nessa mensagem de commit é a substância deste post, e o próximo passo sobre isso é o que quero registrar.
Como o MCP se parece no runtime hoje
Seis ferramentas, em um servidor Python em src/mcp/raku_mcp_server.py, transporte sobre stdio, namespace raku.*. Permissões negadas por padrão aplicadas por ferramenta e por chamador. Toda chamada registrada em um log de auditoria.
As seis ferramentas:
load_world_model(adapter_name, config)registra um backend de modelo de mundo. Hoje os nomes de adaptador são placeholders:VideoPredictor-v2,NeuralRadianceField,PhysicsFoundation. Amanhã serão adaptadores reais.ingest_frame(adapter_name, frame_data, frame_index, timestamp)entrega um frame de um modelo generativo para o grafo de cena do runtime.get_scene_state(include_physics, include_transforms)é o retrato somente-leitura do mundo. Seguro em todo modo.set_render_target(target_type, config)configura onde o mundo renderiza: WebGL, headset de VR, janela nativa, fora de tela.start_simulation(tick_rate, max_duration, realtime)inicia o loop de simulação. Apenas sandbox e dev. Servidores de produção recusam essa chamada.get_metrics()retorna um retrato de desempenho. FPS, tempo de frame, contagem de nós, carga do adaptador, tempo de atividade. Seguro em todo modo.
Ferramentas somente-leitura funcionam em todo ambiente. Ferramentas de mutação (load, ingest, set, start) funcionam apenas em sandbox e dev. A postura de produção é “agentes externos podem perguntar, não mandar.” Essa postura é aplicada no servidor, não no chamador. Um parceiro mal-comportado não consegue mutar um modelo de mundo de produção por acidente.
Por que essas seis e não outra coisa
A versão inicial do servidor MCP, antes de março, expunha ferramentas de agente de jogo: move_npc, set_dialog, place_object, query_inventory. Essas são as ferramentas erradas para a fronteira. São preocupações de nível de aplicação, não de nível de engine. Elas fazem do engine a coisa em que o agente mexe por dentro. O engine deveria ser a coisa sobre a qual o agente roda em cima.
O reenquadramento no PR #1311 trocou a superfície de ferramentas. As novas ferramentas operam sobre abstrações de modelo de mundo: carregar um backend, empurrar um frame, consultar estado, configurar renderização, iniciar simulação, ler métricas. Um agente que quer mover um NPC faz isso empurrando um frame através do adaptador de modelo de mundo, não chamando move_npc no engine. O engine permanece a autoridade sobre física, colisão, pontuação, estado multiplayer. O modelo de mundo é um contribuinte, não um controlador.
Essa distinção é o que permite ao engine ser agnóstico sobre qual modelo de mundo está do outro lado. Genie, Runway, Sora antes de ser encerrado, um modelo interno personalizado, um modelo de fundação de física, um renderizador experimental de campo de radiância neural. Todos falam a mesma superfície de seis ferramentas. Nenhum deles pode sobrepor a autoridade do engine sobre o que está de fato acontecendo na simulação.
É isso que “runtime de autoridade determinística” significa na prática. Usamos essa frase bastante em conversas com parceiros. A superfície MCP é o que a torna verdadeira.
A lacuna entre hoje e o que vem a seguir
A versão honesta de onde o MCP está: o servidor é real, a camada de segurança é robusta, os esquemas são tipados, o log de auditoria funciona, e os adaptadores são stubs.
Essa última palavra é o peso deste sábado. As seis ferramentas aceitam uma string adapter_name. Os adaptadores stub (VideoPredictor-v2, NeuralRadianceField, PhysicsFoundation) são placeholders que comprovam o caminho de despacho. Há arquivos de andaime em src/environment/ para VeoEnvironmentAdapter e RunwayEnvironmentAdapter que ainda não estão conectados a um modelo real.
O próximo passo é um adaptador, de ponta a ponta, com um modelo de parceiro real do outro lado. O candidato que continua aparecendo nas conversas desde a GDC é um preditor de vídeo (Runway, ou um modelo aberto menor) alimentando dados de quadro de cena através de ingest_frame enquanto o engine cuida de física e colisão por baixo. Um demo onde os visuais vêm de um modelo generativo e o gameplay vem do engine, e nenhum dos dois lados precisa saber do outro exceto através da fronteira MCP.
Se esse demo funcionar, todo outro adaptador é uma forma conhecida. A parte difícil não é a integração. A parte difícil é o contrato. O contrato são as seis ferramentas.
O que isso significa para parceiros
Duas coisas específicas, ambas valem a pena dizer em voz alta.
Qualquer agente que fale MCP pode conduzir o runtime. Um laboratório de modelos que quer testar sua geração contra um engine real não precisa de uma integração personalizada. Ele escreve um cliente MCP, chama load_world_model com o backend deles, empurra frames com ingest_frame, lê o estado da cena com get_scene_state. O engine faz o resto. O parceiro ganha uma superfície de avaliação real para o modelo dele. Nós ganhamos uma demonstração real de que o engine é agnóstico de fornecedor.
Qualquer desenvolvedor construindo ferramentas em cima do runtime pode usar a mesma superfície. O servidor MCP não é uma API só-para-parceiros. É a API. Um estúdio construindo uma ferramenta de autoria, um pesquisador rodando avaliações em lote, um parceiro de hardware integrando um novo sensor, todos recebem as mesmas seis ferramentas. Não existe uma API “interna” separada escondida atrás da pública. Existe a superfície MCP e existe a API em C que o SDK usa, e isso é toda a face pública do runtime.
O endurecimento que ainda falta fazer
Três pedaços de trabalho que quero registrar para que sejam feitos:
Arcabouço de implantação de produção. O servidor MCP hoje é instanciado em testes. Precisa de um template de serviço: configuração por variável de ambiente para modo, tokens de autenticação e limites de taxa, um endpoint de verificação de saúde, encerramento gracioso, empacotamento em contêiner. Higiene operacional padrão. Nada glamoroso. A coisa que transforma um servidor funcional em um implantável.
Fallback multi-provedor. Quando o adaptador primário está lento ou indisponível, o servidor deveria conseguir rotear para um secundário. O documento de estratégia fala disso há um tempo. A implementação ainda não chegou. A forma é direta. Os testes serão o trabalho.
Programa de recompensas de adaptador. Assim que um adaptador funcionar de ponta a ponta e o contrato estiver comprovado, o movimento certo é publicar o contrato do adaptador e convidar o ecossistema a escrever mais. Um adaptador Genie de alguém que conhece Genie. Um adaptador Marble de alguém que conhece Marble. Um adaptador de modelo personalizado de um grupo de pesquisa. Nosso trabalho para de ser “integrar todo modelo” e passa a ser “publicar o contrato e revisar as implementações.”
Esse último movimento é o que mais me anima. É o ponto de inflexão em que o MCP para de ser uma ferramenta que construímos para uso próprio e passa a ser infraestrutura sobre a qual outras pessoas constroem.
A semana à frente
A fila que estou registrando nesta manhã de sábado tem o primeiro adaptador real nela. Escopo específico, alvo estreito, demo funcional até o fim do mês se tudo correr bem. Se não correr bem, aprendemos o que erramos sobre o contrato enquanto ainda é barato mudar.
Se você está em um laboratório de modelos e tem uma opinião sobre como fronteiras estilo MCP deveriam se parecer para runtimes que conversam com modelos generativos, esta é a semana certa para compartilhá-la. O contrato ainda não está travado. Comentários custam menos agora do que vão custar em um trimestre.
Seis ferramentas, implantadas, auditadas, tipadas por esquema, negadas por padrão. Adaptadores a seguir. A fronteira é real. O trabalho que roda em cima dela é o que vem depois.
Sábado em movimento.
Conduza um engine de verdade através de um único contrato MCP
Se seu modelo fala Model Context Protocol, ele pode orquestrar um runtime espacial de produção — agnóstico de fornecedor, negado por padrão, toda chamada auditada. O contrato está aberto para comentários enquanto ainda é barato moldá-lo.