MCP Fantom
Recherche sémantique de code pour Fantom et Axon -- GPU local ou OpenRouter
Enseignez à votre assistant IA Fantom et Axon -- avec ou sans GPU de votre côté.
MCP Fantom donne à un assistant IA une connaissance pratique d'une base de code Fantom, Haxall et SkySpark -- pas seulement sa documentation, mais le code réel : qui appelle qui, ce qui a changé la semaine dernière, et quelle fonction fait ce que vous décrivez en langage naturel.
Il indexe les sources Fantom, les fonctions SkySpark Axon, et la documentation de fantom.org et haxall.io ; les intègre tous pour la recherche sémantique ; construit un vrai graphe d'appels ; et les expose via le Model Context Protocol, aux côtés d'un tableau de bord web pour exécuter et surveiller l'indexation.
Nouveau en 1.0 : OpenRouter
L'intégration n'a plus besoin d'un GPU sous votre bureau. Chaque rôle d'inférence -- intégration de code, intégration de texte, reclassement, assistant de code et boucle de récupération -- est acheminé indépendamment vers les hôtes locaux, vers OpenRouter, ou vers les deux à la fois. Exécutez-le entièrement dans le cloud depuis un ordinateur portable, entièrement sur votre propre matériel dans une usine isolée, ou dispersez-vous sur les deux pools en tirant d'une seule file d'attente.
Il migre toujours SkySpark
SkySpark 4.0 a changé le format d'extension. Migrer manuellement une extension ou un connecteur du monde réel est un calvaire de réécritures using, de conversions de chaînes Axon et de nouveaux fichiers de bibliothèque Xeto -- avec un compilateur qui se met en travers au moment où vous manquez une ligne. MCP Fantom réécrit les déclarations using, convertit les chaînes Axon, génère les fichiers Xeto, valide avec le compilateur Fantom et crée une balise de sauvegarde Git en chemin.
Si la migration échoue, annulez avec un appel d'outil. Tout le trajet est diffable, réversible et narré.
À qui c'est destiné
- Auteurs d'extensions migrant les pods SkySpark 3.x vers 4.0
- Intégrateurs Haxall construisant des connecteurs, des fonctions et des applications en Fantom
- Développeurs SkySpark qui veulent que leurs fonctions Axon soient recherchables par sens plutôt que par grep
- Développeurs assistés par IA qui ont besoin d'un contexte Fantom précis, pas d'une syntaxe imaginée
Cockpit de migration
Migrez SkySpark 3 à 4 sans crampes aux mains
Un outil réécrit votre extension. Un autre la valide. Un tiers l'annule. Chaque changement est diffable, le compilateur vérifie, Git conserve le filet de sécurité.
fan compile. Annulation disponible via rollbackMigration jusqu'à ce que commitMigration soit appelé.
Indexation Lazy
Le serveur répond avant que l'index ne finisse
La plupart des serveurs de recherche bloquent le client pendant 30 à 60 secondes au premier démarrage pendant qu'ils indexent. MCP Fantom démarre en moins d'une seconde. Les outils répondent immédiatement -- FlexSearch se réchauffe en premier, les pods locaux ensuite, les intégrations après. L'assistant ne jamais attend.
Les requêtes se dégradent de manière transparente. Si les intégrations ne sont pas prêtes, les outils sémantiques reviennent à la recherche par mot-clé. L'assistant obtient une réponse avec une note sur la fidélité, pas un délai d'attente.
Intelligence de code
Compréhension sémantique, pas seulement correspondance de texte
semanticCodeSearch et findSimilarCode intègrent votre code Fantom dans un espace vectoriel. Demandez "fonctions qui normalisent les unités" et obtenez des résultats qui partagent la structure, pas les mots-clés.
Graphology avec clustering Louvain trouve les communautés naturelles dans votre base de code -- quels types vont ensemble, lesquels ne le font pas. getCodeImpact trace la propagation d'une modification. getCallers et getCallees complètent la surface du graphe d'appels.
Sécurité de migration
Chaque migration est à une annulation près
migrateSkySpark4x crée une balise Git avant d'écrire un seul octet. Si quelque chose échoue -- erreur du compilateur, inadéquation de validation, votre intuition -- rollbackMigration restaure le repo à l'état exact avant l'exécution.
commitMigration est délibéré. Rien n'est fusionné dans votre historique de travail jusqu'à ce que vous acceptiez la sortie. Jusque-là, la migration vit sur une branche, avec une balise de sauvegarde, prête à être abandonnée.
using + conversion Axon + génération Xeto.migrateSkySpark4x a été appelé.skyspark-4x-migration, connector-workflow, et xeto-spec-guide.Flux de travail guidés
Au-delà des outils -- des guides lisibles
Les ressources MCP sont des documents markdown que l'assistant peut lire à la demande. MCP Fantom en contient treize : un structureur de pod, un guide de publication fanr, une procédure pas à pas d'extension Haxall, une amorce de test unitaire fant, un playbook de migration SkySpark 4.x, un guide de spécification Xeto, et plus encore.
Quand un développeur demande "par où commencer ?", l'assistant récupère la bonne ressource, résume et procède. Chaque flux de travail est versionné aux côtés du serveur.
- ✓ Markdown étape par étape
- ✓ Découvrable via
ressources/list - ✓ Versionné avec le serveur
- ✓ Facile à ajouter plus
Routage de fournisseur
Votre GPU, OpenRouter, ou les deux à la fois
Chaque rôle d'inférence est acheminé par lui-même. L'intégration peut se disperser sur les GPUs locaux et OpenRouter en tirant d'une seule file d'attente, tandis que le reclassement ne s'exécute que sur le cloud et la boucle de récupération reste sur site. Quatre politiques, cinq rôles, définis par rôle et modifiés à l'exécution.
Un rôle pointé vers OpenRouter devient un conteneur virtuel : une capacité de service réelle sans GPU et sans VRAM derrière, enregistré comme son propre fournisseur logique pour que le planificateur puisse lui donner du travail comme n'importe quel autre hôte. Pas de modèle local signifie pas de exigence matérielle locale -- MCP Fantom indexe une base de code à partir d'un ordinateur portable.
- ✓
aggregate-- local et cloud dans un pool fan-out - ✓
backup-- local en premier, cloud en réserve - ✓
local-- isolé, rien ne quitte le réseau - ✓
cloud-- OpenRouter uniquement, aucun GPU requis
0.99 cosinus, à la dimension exactement configurée, avant de pouvoir écrire une seule ligne.
Pile technologique
Architecture
Capacités
- 41 outils MCP -- couvrant la recherche de documentation, la recherche sémantique de code, l'analyse de graphe d'appels, l'historique du code, la génération de code et l'automatisation de migration
- Routage de fournisseur par rôle --
code-embedding,embedding,reranker,code-assistant, etrlmprennent chacun leur propre politique :local,cloud(OpenRouter uniquement),aggregate(les deux dans un pool fan-out), oubackup(local en premier, cloud en réserve) - Indexation lazy -- le serveur démarre en quelques secondes et répond immédiatement ; l'indexation s'exécute en arrière-plan et les outils se dégradent gracieusement pendant ce temps
- Recherche sémantique -- LanceDB derrière un index ANN, avec un cross-encoder optionnel ou un reclasseur OpenRouter
- Q&A en langage naturel --
askCodebaseexécute une boucle de récupération sur l'index et synthétise une réponse citée - Un vrai graphe d'appels --
getCallers,getCallees,getCodeImpact, etgetCodeNeighborsrépondent aux questions structurelles à partir d'une base de données de graphe intégrée, pas en faisant du grep - Support Axon -- Fonctions SkySpark Axon, à partir de dossiers
proj/synchronisés ou d'exportations de bibliothèque hors ligne, analysées avec une grammaire tree-sitter dédiée pour que les chunks atterrissent sur les limites des déclarations et les cellulesdefcompse surface en tant qu'interface du composant - Historique --
whatChangedRecently,getSymbolHistory,explainSymbolChange, etdiffIndexRunsrépondent à la façon dont le code en est arrivé là - Migration SkySpark 4.x -- réécriture automatisée des déclarations
usinget des chaînes Axon, génération de fichiers Xeto (lib.trio,funcs.xeto,lib.xeto), validation du compilateur, balise de sauvegarde Git, annulation en un appel - 13 ressources de flux de travail -- des guides markdown lisibles, de
create-podàskyspark-4x-migration - Double transport -- stdio et HTTP, avec un tableau de bord Next.js pour la couverture d'index, la progression de l'intégration et le routage de fournisseur
Cloud sans les pièges
Déposer un intégrateur cloud dans un index qu'un GPU local a construit est la façon dont la récupération pourrit tranquillement -- la distance cosinus cesse d'être comparable et rien ne vous le dit. MCP Fantom traite cela comme une précondition stricte plutôt que comme un avertissement :
- Portail de compatibilité vectorielle -- un fournisseur cloud intègre des textes de sonde aux côtés d'un fournisseur de référence et doit passer un cosinus minimum de 0,99, exactement à la dimension configurée, avant de pouvoir écrire une seule ligne. L'encodeur de requête vient toujours du pool qui a construit ces lignes.
- Amonts épinglés -- deux hôtes OpenRouter servant le même slug de modèle ne garantissent pas des vecteurs identiques, donc chaque route d'intégration doit nommer son amont. Le reclassement est sans état et n'a besoin d'aucune épingle.
- Un budget partagé -- OpenRouter applique des limites de débit par clé, pas par appelant, donc toute la concurrence cloud est tirée d'un seul pool de permis global, dimensionné à partir de la latence mesurée par la loi de Little. Un 429 divise par deux le budget et recule avec gigue ; les GPUs locaux continuent à fonctionner directement.
- Clés en écriture seule -- la clé API passe au sidecar qui l'utilise. Elle n'est jamais écrite en config, jamais enregistrée et jamais renvoyée par aucun endpoint.
Surface d'outils (partielle)
searchFantomCode, semanticCodeSearch, askCodebase, findSimilarCode, getFantomType, getFantomFunction, searchLocalDocs, searchVersionedApi, listFantomPods, getCallers, getCallees, getCodeImpact, getCodeNeighbors, whatChangedRecently, getSymbolHistory, explainSymbolChange, diffIndexRuns, axonSearch, axonFunction, generateFantomCode, migrateSkySpark4x, commitMigration, rollbackMigration, plus la gestion des projets et des instances.
Exigences
- Node.js 20+
- Un fournisseur d'intégration -- un modèle local ou une clé OpenRouter
- Chaîne d'outils locale Fantom et Haxall pour la validation du compilateur de migration
- Dépôt Git pour les sauvegardes de migration
Intéressé par ce projet ?
Explorez le code source, contribuez ou prenez contact.