Install
cargo build --releaseÀ qui ça s’adresse
Si un assistant ou un script doit atteindre le série/UART, et que le même flux doit servir d’outil MCP et de ligne de commande, serial-mcp-server correspond. Il fournit un service MCP stdio et une CLI scriptable pour la CI et pour un agent skill sans configuration MCP. La cible de publication actuelle est 0.3.0.
Il convient à qui a déjà Rust 1.74 ou plus récent sur cette machine, peut fournir un périphérique série ou un adaptateur USB-série pendant le travail matériel, et a les droits système de ce port. Dépôt :
https://github.com/adancurusul/serial-mcp-server
Si vous voulez seulement cliquer dans un navigateur, sans environnement de compilation, arrêtez-vous ici — l’entrée officielle est cloner puis cargo build --release.
Premier essai en 3 minutes
Le chemin principal officiel est compiler depuis les sources. Prérequis : Rust 1.74+. La première fois, ne pas brancher un vrai périphérique : seulement énumérer les ports locaux, pour ne pas écrire un port série par erreur.
L’emplacement d’installation est la racine du dépôt cloné :
git clone https://github.com/adancurusul/serial-mcp-server.git
cd serial-mcp-server
cargo build --release
Le binaire est dans target/release/serial-mcp-server. On peut aussi cargo install --path . --locked vers PATH, mais la première fois le binaire construit dans le dépôt suffit.
Premier appel à bas risque :
serial-mcp-server list-ports --json
C’est une énumération en lecture seule ; elle n’écrit pas de données vers un périphérique. On peut aussi lancer serial-mcp-server --help d’abord pour confirmer que la commande est là. Ne pas traiter les espaces réservés de port de la doc comme un vrai nom d’appareil à écrire.
Signal de succès observable : list-ports --json affiche un JSON de ports (il peut être vide) et le processus se termine normalement. Si les droits manquent, régler d’abord les droits OS du port série choisi ; ne pas changer pour un lanceur non documenté.
Cas d’usage
Cas 1 : voir quels ports existent, puis en sonder un. Les commandes correspondantes sont list-ports --json et probe avec --baud 115200 --json. Les noms de ports doivent venir de cette sortie ; ne pas écrire à la main un chemin fictif. probe atteint le matériel ; confirmer que l’appareil est branché avant d’exécuter.
Cas 2 : rassembler une séquence temporelle en plusieurs étapes dans une macro JSON. Les appareils ont souvent besoin de : envoyer une commande, attendre quelques millisecondes, lire une invite ou une réponse, puis envoyer la suivante. Le paquet macro enregistre ce processus pour qu’une personne, une CLI ou un assistant fasse macro validate, macro list, macro plan, et simule sans matériel. Côté MCP, il y a aussi chargement / énumération / déchargement de paquets macro en mémoire, plan et run. Un vrai macro run ou write/read opère un vrai port ; confirmer le câble d’abord.
Limites d’usage
0.3.0 a retiré Quick de l’API publique ; un usage de style Quick doit s’écrire en macros. Ne plus chercher une interface Quick.
Les données d’exemple par défaut de write sont H, avec --read --timeout-ms 1000 --json ; cela envoie des données vers le port. Les extraits de délai et de débit ne montrent que 115200 et 1000 ms ; ce ne sont pas des valeurs sûres par défaut pour tous les appareils.
Pas d’interface graphique ni de série cloud décrits. MCP est stdio. Aucun client n’est nommé. Les macros peuvent d’abord être simulées, mais run peut encore changer l’état de l’appareil. Sans droits ou sans pilote, les commandes matérielles échouent.