Uno Platform porta MCP nelle app .NET: Microduck apre l’AI fisica

🤖 Cosa cambia

• Uno Platform separa documentazione e applicazione in due server MCP, permettendo agli agenti di generare, eseguire e verificare interfacce .NET.
• Screenshot, albero visuale, Hot Reload e automazione consentono all’AI di controllare il risultato prodotto invece di limitarsi a scrivere codice.
• Microduck non è un modello linguistico, ma un robot bipede open source addestrabile in simulazione tramite reinforcement learning.

Uno Platform integra Model Context Protocol nello sviluppo cross-platform .NET per trasformare gli assistenti di programmazione in agenti capaci di consultare la documentazione, avviare un’applicazione, osservarne l’interfaccia e verificare autonomamente il risultato. Hugging Face e Pollen Robotics spostano la stessa logica nel mondo fisico con Microduck, un piccolo robot open source addestrabile attraverso reinforcement learning. Non si tratta quindi, come inizialmente indicato, di un modello linguistico compatto per dispositivi edge: Microduck è una piattaforma robotica da 25 centimetri dotata di sensori, quindici motori e policy comportamentali modificabili. I due progetti affrontano su livelli differenti lo stesso limite dell’AI: generare un risultato non significa averne verificato il funzionamento.

Uno Platform divide MCP tra conoscenza e controllo dell’applicazione

L’architettura sviluppata da Uno Platform nasce dalla constatazione che riempire il prompt con documentazione tecnica non garantisce né accuratezza né capacità di verifica. Un agente può produrre una pagina apparentemente corretta, compilare il codice e rispettare le regole sintattiche, ma non sapere se pulsanti, navigazione e layout funzionino realmente sul dispositivo di destinazione. Uno Platform risponde separando le attività in due server MCP costruiti in C# con l’SDK ufficiale mantenuto da Microsoft insieme alla comunità. Il primo è un server documentale pubblico, stateless e raggiungibile via HTTP: cerca nelle guide ufficiali, restituisce pagine in Markdown e inizializza le regole necessarie per lavorare sul framework. La conoscenza viene aggiornata insieme alla documentazione, evitando di distribuire indicazioni obsolete dentro un pacchetto NuGet. Il secondo server viene eseguito localmente attraverso stdio, mantiene lo stato della singola sessione e collega l’agente a Uno DevServer. Può avviare l’applicazione in modalità debug, attivare Hot Reload, acquisire screenshot, leggere in XML l’albero visuale e interagire con l’interfaccia attraverso clic, pressione dei tasti, inserimento di testo e automation peer. La distinzione è funzionale: il server documentale descrive ciò che dovrebbe essere vero, quello applicativo osserva ciò che sta accadendo realmente. Il progetto e le scelte architetturali sono illustrati nell’approfondimento ufficiale pubblicato sul blog .NET di Microsoft.

Leggi anche: L’AI esce dal cloud tra MCP stateless, kernel portabili e robot Jetson

L’agente .NET può eseguire e controllare il codice che produce

La novità più importante non consiste nella generazione automatica dell’interfaccia, ormai disponibile in numerosi strumenti, ma nella possibilità di chiudere il ciclo tra scrittura, esecuzione, osservazione e correzione. Uno Platform paragona il proprio app server a un sistema di automazione simile a Playwright per applicazioni native e cross-platform .NET. Dopo una modifica, l’agente può attendere l’aggiornamento tramite Hot Reload, acquisire l’immagine dell’interfaccia, leggere la struttura degli elementi e attraversare il flusso applicativo. Lo screenshot permette di rilevare un errore visivo; l’albero XML consente di identificare l’elemento, le proprietà e la gerarchia che lo hanno provocato. Gli automation peer vengono preferiti ai clic basati sulle coordinate perché risultano più stabili quando cambiano risoluzione, dimensioni della finestra o densità dello schermo. Uno Platform aggiunge una libreria di Skills che descrive l’ordine nel quale utilizzare gli strumenti per attività come navigazione, gestione dello stato, temi e test dell’interfaccia. Uno Platform Studio 3.0 combina questa struttura con Roslyn e Microsoft Agent Framework per generare e compilare nel browser un’applicazione .NET completa, caricandone gli assembly e le dipendenze NuGet prima di mostrarla in esecuzione. Il risultato può essere successivamente trasferito agli ambienti IDE e CLI tradizionali. Questa evoluzione completa il percorso nel quale C# 15 e Foundry Hosted Agents avvicinano linguaggio, runtime e distribuzione degli agenti, ma introduce anche un costo da controllare: definizioni e schemi degli strumenti MCP occupano spazio contestuale prima ancora che il modello inizi a lavorare.

Gli strumenti MCP consumano contesto e richiedono descrizioni precise

Uno Platform quantifica il peso dei propri strumenti: il server documentale occupa circa 6.400 token, quello applicativo circa 1.500, mentre nella stessa sessione il server MCP integrato di GitHub richiede approssimativamente 5.200 token. Nomi, descrizioni e schemi di input vengono caricati nel contesto prima dell’esecuzione della prima attività. Un catalogo troppo esteso può quindi sottrarre spazio al codice e alle informazioni necessarie per completare il lavoro.

Le descrizioni non costituiscono una semplice documentazione per lo sviluppatore, ma istruzioni che influenzano direttamente la scelta del modello: uno strumento descritto male potrebbe non essere mai richiamato oppure essere utilizzato nel momento sbagliato. Uno Platform raccomanda per questo di dividere i server secondo la durata dello stato e non secondo categorie funzionali arbitrarie. La conoscenza aggiornata con le release può vivere su un servizio HTTP condiviso; lo stato di un’applicazione in esecuzione deve invece rimanere vicino al processo locale. La topologia determina anche il trasporto: HTTP è adatto a un servizio multi-tenant autenticato, mentre stdio riduce l’esposizione quando il server è un processo figlio collegato a una sola applicazione. L’approccio non rende infallibile l’agente, ma sostituisce una parte della fiducia nel testo generato con prove sull’applicazione realmente in esecuzione.

Microduck porta l’addestramento open source in un robot da 25 centimetri

Sul versante hardware, Hugging Face e Pollen Robotics hanno presentato Microduck, un robot bipede open source alto 25 centimetri e proposto in preordine a 399 dollari, escluse imposte e spedizione. La consegna è prevista prima di Natale 2026. Il dispositivo utilizza quindici motori, una videocamera, un sensore LiDAR e due unità inerziali; il becco funziona anche come elemento di presa e può sollevare oggetti fino a 800 grammi. Le sette policy preinstallate gestiscono azioni come camminare, sedersi, rialzarsi dopo una caduta, calciare, afferrare piccoli oggetti e muoversi con pattini applicabili ai piedi. Il ciclo delle policy viene eseguito a 50 Hz.

Il punto centrale non è però l’aspetto da giocattolo, ma la pipeline sim-to-real: ogni comportamento può essere addestrato in un ambiente MuJoCo sul computer dello sviluppatore o tramite Hugging Face Jobs, trasferito al robot, perfezionato nella simulazione e infine condiviso con la comunità. SDK, simulatore e stack di reinforcement learning sono pubblicati con licenza Apache 2.0. La scheda ufficiale di Microduck pubblicata da Pollen Robotics conferma quindi che il prodotto non appartiene alla categoria degli LLM compatti per edge device, ma a quella delle piattaforme accessibili per sperimentare controllo motorio, reinforcement learning e intelligenza artificiale fisica.

Continua con:

Nvidia e Hugging Face aprono modelli e strumenti per la robotica AI

La verifica diventa il vero terreno comune tra software e robotica

Uno Platform e Microduck appartengono a mercati differenti, ma condividono una scelta progettuale precisa: l’AI deve poter confrontare il risultato generato con un ambiente osservabile. Nel primo caso l’agente verifica un’applicazione attraverso compilazione, screenshot, albero visuale e automazione dell’interfaccia. Nel secondo una policy viene addestrata nella simulazione, trasferita al robot e corretta quando la risposta del sistema fisico non coincide con quella prevista. La generazione diventa soltanto una fase del ciclo, non la prova della correttezza. Per gli sviluppatori .NET questo significa integrare agenti che conoscano il framework e sappiano controllare un’applicazione in esecuzione. Per la comunità Hugging Face significa disporre di una piattaforma robotica relativamente economica sulla quale sperimentare policy riproducibili e condivisibili. Entrambi i progetti riducono la distanza tra istruzione e azione, ma rendono ancora più importante governare strumenti, autorizzazioni, costi contestuali e verifiche. L’AI applicata allo sviluppo e alla robotica diventa utile quando può vedere ciò che ha prodotto, misurarlo e correggerlo prima di affidarlo all’utente.