Demandez à un modèle de langage généraliste d'écrire une fonction Axon et vous obtiendrez l'une de ces deux réponses. L'honnête est un refus poli. La dangereuse est un bloc de code assuré appelant rollupByDay() — une fonction qui n'a jamais existé dans aucune version de SkySpark.
Ce n'est pas un défaut d'intelligence. C'est un défaut d'exposition. Axon est un langage dédié à la construction d'analyses : petit, étrange et magnifique, avec un modèle de requête folio et un système de composants defcomp qui ne ressemblent à rien d'autre dans un corpus d'entraînement. Le modèle a lu des millions de lignes de Python. Il n'a lu à peu près aucune des vôtres.
Axon MCP Server existe pour corriger cela, et il le fait de la manière la plus ennuyeuse qui soit : non pas en affinant un modèle, mais en plaçant le corpus réel à un appel d'outil de distance.
La forme du problème
Une fonction Axon hallucinée est pire que pas de réponse du tout. En Python, une méthode inventée lève une AttributeError en une seconde. Dans une plateforme d'analyse du bâtiment, une règle d'apparence plausible peut passer une vérification syntaxique, être déployée sur un site en production et produire discrètement de mauvais chiffres de consommation pendant un mois avant que quiconque ne remarque la dérive de la ligne de base.
L'exigence n'a donc jamais été « faire en sorte que l'assistant ait l'air compétent ». Elle était : chaque suggestion doit provenir de quelque chose qui existe réellement, et l'assistant doit être capable de le prouver.
Ce qui est indexé
Axon MCP Server indexe trois choses et les expose toutes via le Model Context Protocol :
- La documentation SkySpark — des milliers de pages HTML explorées et découpées
- Les fonctions Axon — issues des dossiers de projet synchronisés et des exports de bibliothèques hors ligne
- Les usages des opérateurs — de vrais sites d'appel, pas seulement des signatures
Les chiffres phares de la version actuelle : plus de 4 000 pages de documentation indexées en 30 à 60 secondes, des requêtes traitées en moins de 50 millisecondes, et un cache de 24 heures pour que les démarrages suivants soient instantanés plutôt qu'une nouvelle exploration à froid.
Pourquoi l'analyseur compte plus que le modèle d'embedding
Il est tentant de considérer l'indexation comme un problème résolu : on découpe le fichier tous les 500 tokens, on vectorise les fragments, et on passe à autre chose. Cela fonctionne acceptablement pour de la prose et très mal pour du code.
Découpez une fonction Axon à un nombre fixe de caractères et vous coupez régulièrement un bloc do ... end en deux. Le premier fragment contient une condition sans corps. Le second, un corps sans condition. Les deux se vectorisent en représentations qui ne signifient à peu près rien, et les deux remonteront volontiers dans les résultats de recherche.
Axon MCP Server analyse plutôt avec une grammaire tree-sitter conçue sur mesure. Cela apporte trois bénéfices concrets :
- Les fragments s'alignent sur les limites d'instructions. Un fragment récupéré constitue une pensée complète, si bien que l'assistant qui le lit voit du code valide.
- Les cellules
defcompsont exposées comme l'interface du composant. Lorsque quelqu'un demande ce qu'un composant prend en entrée et retourne, cette question obtient une réponse structurée plutôt qu'une supposition tirée du texte environnant. - Les commentaires sont conservés comme signal de recherche. La phrase expliquant pourquoi une règle existe est très souvent la meilleure correspondance pour une question en langage naturel, et un analyseur naïf la jette comme n'étant pas du code.
Le modèle d'embedding récolte les lauriers de la recherche sémantique. C'est la grammaire qui rend ce qu'il vectorise digne d'être cherché.
Ancré, pas éloquent
La différence que cela produit n'a rien de subtil.
La colonne de droite, c'est tout le produit. L'assistant ne cherche pas à être malin ; il est redevable. Il a trouvé quelque chose, il peut montrer d'où cela vient, et le graphe d'appels qu'il a emprunté pour y parvenir est bidirectionnel — vous pouvez demander qui appelle une fonction aussi facilement que ce qu'elle appelle.
La pile technique, en bref
Du TypeScript de bout en bout, parlant le Model Context Protocol. FlexSearch pour la recherche par mots-clés, LanceDB avec des embeddings HuggingFace Transformers pour la recherche sémantique, tree-sitter pour la structure, Prisma sur SQLite pour les métadonnées de projet et d'exécutions d'indexation, et OAuth 2.1 sur le point d'accès web.
L'exécution requiert Node.js 20 ou une version plus récente. Tout le reste fonctionne hors ligne ; une instance SkySpark active est facultative et ne débloque que les fonctionnalités d'exécution et de requêtes en direct.
À qui cela s'adresse vraiment
- Les développeurs SkySpark écrivant de la logique CVC, énergie et sparks, qui veulent un binôme de programmation connaissant la plateforme plutôt qu'un outil qui lui applique des motifs Python
- Les intégrateurs en automatisation du bâtiment qui consolident un savoir aujourd'hui réparti entre une douzaine de dossiers de projet et la mémoire d'un ingénieur senior
- Les développeurs assistés par IA qui ont besoin d'un contexte fiable et qui ont appris à se méfier d'une syntaxe trop assurée
Ce dernier groupe est le public le plus sincère. La valeur ici ne tient pas à ce que l'assistant devienne plus intelligent. Elle tient à ce qu'il cesse d'avoir tort avec assurance à propos d'un langage qu'on ne lui a jamais enseigné.
Axon MCP Server est disponible en source ouverte sur github.com/Project-SandStar/AxonMcpServer. La page du projet présente l'ensemble des outils et le guide d'installation.