SmeltSecSmeltSec
    Features
    |Security
    |How It Works
    |Pricing
    |Docs
    |Blog
    |About
    npm
    1. Home
    2. /
    3. How it works
    PROCESSUS

    Du Code Source à la Production en 60 Secondes

    Huit étapes. Chacune prend une entrée, exécute une action, produit une sortie. Pointez SmeltSec vers un dépôt ou une spec OpenAPI ; obtenez un serveur MCP signé, noté, prêt à déployer.

    1
    Ingestion de la source
    2
    Analyse du code base
    3
    Génération des définitions d'outils
    4
    Génération du code serveur
    5
    Gate 1
    6
    Gate 2
    7
    Score de qualité
    8
    Attestation + déploiement
    1
    ÉTAPE 1

    Ingestion de la source

    Entrée : dépôt GitHub, spec OpenAPI ou langage naturel

    Pointez SmeltSec vers une des trois sources. Une URL GitHub publique ou privée déclenche un clone. Un document OpenAPI 3.0/3.1 est parsé directement. Une description en langage naturel récupère la doc SDK pertinente. Sortie : un bundle source normalisé, prêt pour l'AST.

    Équivalent API
    POST /v1/generate { source: 'github', repo: 'owner/repo' }
    Analyse de la Source
    ◆ Analyse du dépôt... 342 files, 89 functions discovered
    ◆ Analyse Tree-sitter... Python AST extracted for 89 functions
    ◆ Cartographie de la surface API... 14 public endpoints, 75 internal filtered
    ✓ Détection des routes : Flask routes (GET: 8, POST: 4, PUT: 2)
    ✓ Analyse d'authentification : 12/14 endpoints require @auth_required
    ✓ Prêt pour la Porte 1 14 tool candidates identified
    2
    ÉTAPE 2

    Analyse du code base

    Entrée : bundle source → AST Tree-sitter

    Tree-sitter parse le bundle et émet un AST typé par fichier. SmeltSec parcourt l'arbre, extrait les signatures de fonctions publiques et les handlers de route, et filtre tout ce qui est marqué internal ou deprecated. Sortie : une liste de candidats appelables avec leurs annotations de type.

    Équivalent API
    GET /v1/servers/{id}/security/gate1
    Porte 1 — Scan Pré-Génération
    ◆ Semgrep SAST : 342 files scanned — 0 critical, 1 warning (unsafe pattern usage)
    ◆ Gitleaks : Code + git history — 0 secrets found
    ◆ OSV-Scanner : 23 deps — 1 medium CVE (requests 2.28)
    ◆ Surface API : 14 endpoints mapped, auth requirements logged
    ✓ Décision Porte 1 : PASSED — 0 blockers, 2 warnings
    3
    ÉTAPE 3

    Génération des définitions d'outils

    Entrée : candidats AST → schémas d'outils MCP typés

    Un pass LLM transforme chaque candidat en une définition d'outil MCP : nom, description et un JSON Schema strict pour les arguments et le type de retour. Les docstrings nourrissent les descriptions ; les annotations de type deviennent le schéma. Sortie : un manifeste d'outils typés prêts à câbler dans un serveur.

    Équivalent API
    POST /v1/generate { source: 'github', repo: 'owner/repo' }
    Pipeline de Génération
    ◆ Sélection des outils... 14 tools selected from 89 functions
    ◆ Génération des descriptions... AST + docstring analysis
    ◆ Construction des schémas... Zod schemas from type annotations
    ◆ Génération du serveur... FastMCP + Python 3.11
    ✓ Patterns de code : Retry, circuit breaker, sanitization embedded
    ✓ Serveur généré 14 tools, ready for Gate 2
    4
    ÉTAPE 4

    Génération du code serveur

    Entrée : manifeste d'outils → serveur FastMCP / TypeScript SDK

    Chaque définition d'outil devient un vrai handler. SmeltSec émet du code FastMCP (Python 3.11) ou TypeScript SDK, câble les retries, circuit breakers, sanitation des arguments et le transport choisi. Sortie : un dépôt de serveur MCP exécutable avec dépendances figées.

    Équivalent API
    GET /v1/servers/{id}/security/gate2
    Porte 2 — Scan Post-Génération
    ◆ MCP-Scan : 14 tools scanned — 0 poisoning, 0 hidden instructions
    ◆ Analyse Comportementale : 14/14 tools — intent matches action
    ◆ Semgrep Self-Check : 0 new vulnerabilities introduced
    ◆ Vérification des Permissions : No escalation detected (all tools ≤ source scope)
    ✓ Décision Porte 2 : PASSED — Security Grade: A (91/100)
    5
    ÉTAPE 5

    Gate 1 : scan de sécurité

    Entrée : serveur généré → SAST, secrets, CVE, détection de poisoning

    Tout en local. Tout gratuit. Semgrep exécute les règles SAST, Gitleaks scanne le code et l'historique git pour les secrets, OSV-Scanner vérifie les dépendances épinglées contre la base OSV, MCP-Scan détecte le poisoning de descriptions. Une découverte Critique bloque le pipeline. Sortie : un rapport Gate 1 signé.

    Équivalent API
    POST /v1/score { manifest: '...' }
    Pipeline de Scoring
    ◆ Score Qualité : 87/100 (B) — 6 dimensions
    ◆ Score Sécurité : 91/100 (A) — 5 categories
    ◆ Description : 92/100 | Schema: 88 | Naming: 95
    ◆ Chevauchement : 78/100 — search_docs and find_docs similar
    ✓ Correction auto : 3 suggestions available (+12 points)
    ✓ Rapports générés Quality + Security report cards
    6
    ÉTAPE 6

    Gate 2 : analyse comportementale

    Entrée : rapport Gate 1 + manifeste → vérification comportementale LLM

    Un LLM compare la description de chaque outil à ce que son code fait vraiment. Les écarts apparaissent comme une dérive comportementale : un outil qui prétend lire mais écrit aussi, une description qui cache des effets de bord, une permission jamais déclarée. Cette étape est payante (≈ 0,02 $ par serveur). Sortie : un rapport comportemental avec Pass / Warn / Fail par outil.

    Équivalent API
    GET /v1/servers/{id}/config?client=claude_desktop
    Déploiement & Config
    ✓ Claude Desktop : synced — ~/.config/claude/config.json
    ✓ Cursor : synced — ~/.cursor/mcp.json
    ✓ VS Code : synced — .vscode/mcp.json
    ✓ ChatGPT : synced — plugin manifest
    ✓ Windsurf : synced — ~/.windsurf/mcp.json
    ◆ Démon : running — auto-sync on changes
    7
    ÉTAPE 7

    Score de qualité

    Entrée : serveur + rapports → score sur 6 dimensions

    Six dimensions, une note par serveur : clarté des descriptions, complétude du schéma, cohérence des noms, chevauchement avec les outils existants, surface d'erreur, hooks d'observabilité. Chaque dimension a un score chiffré et une suggestion. Sortie : une fiche de notation (A–F) avec actions concrètes.

    Équivalent API
    POST /v1/servers/{id}/monitor { repoUrl, branch: 'main' }
    Détection des Changements
    ◆ Push détecté : main @ abc1234
    ◆ Calcul des différences : api/users.py (3 functions changed)
    ! Impact ÉLEVÉ : get_user — parameter signature changed
    ~ Impact MOYEN : update_user — return type changed
    · Impact FAIBLE : list_users — docstring updated
    → Mise à jour proposée : Surgical patch (preserves 12 edits)
    8
    ÉTAPE 8

    Attestation + déploiement

    Entrée : serveur validé → attestation signée + configs client

    SmeltSec empaquette le serveur, les deux rapports de gate, le score qualité et un SBOM dans une attestation signée avec cosign. Les configs clients pour Claude Desktop, Cursor, VS Code, ChatGPT et Windsurf sont écrites en une seule passe par le démon de synchronisation. Sortie : un serveur MCP signé et déployable, avec chaque outil câblé dans chaque client.

    Équivalent API
    GET /v1/servers/{id}/analytics?range=7d
    Analytique & Export
    ◆ Total appels (7j) : 12,847
    ◆ Taux d'erreur : 1.2% (below 5% threshold)
    ◆ Latence p95 : 142ms
    ◆ REST API : 51 endpoints, 12 groups
    ◆ Webhooks : 16 events — HMAC-SHA256 signed
    ◆ OTEL push : Grafana / Datadog / custom OTLP endpoint
    Capabilities

    See all capabilities

    Nine modules — generation, security, quality scoring, monitoring, config sync, analytics, API, code patterns, governance — with what each one actually does.

    Deep dives

    Related reading

    We're Building MCP Servers Wrong

    Most MCP servers today are hand-rolled wrappers around REST APIs. Here is why that is a dead end — and what a repeatable pipeline looks like.

    Read post

    From REST API to MCP Server in 10 Minutes

    A walkthrough of the SmeltSec pipeline: point it at a REST endpoint, watch the eight steps run, end with a signed and deployable server.

    Read post

    The Hidden Cost of Not Monitoring Your MCP Servers

    What happens after step eight: upstream drift, silent breakage, and the cost of catching it in production instead of in CI.

    Read post
    FAQ

    Process Questions

    What to expect when running SmeltSec end to end.

    The full eight-step pipeline — source intake, codebase analysis, tool generation, server code generation, Gate 1, Gate 2, quality scoring, and attestation — finishes in under 60 seconds for a medium REST API. Large specs take a few minutes.
    A Critical finding blocks the step. The report gives you exact file paths, scanner IDs, and suggested fixes. Fix the issue and re-run, or waive individual findings with justification on Team and Enterprise plans.
    Yes. Every generation produces a preview you can inspect locally — source code, tool manifests, security reports, and quality score — before you publish it. Nothing deploys automatically.
    Yes. SmeltSec integrates with GitHub, GitLab, and Bitbucket and can pull specs and push generated servers into private repos. Enterprise plans support self-hosted Git and SAML SSO for teams.

    Prêt à commencer ?

    Générez votre premier serveur MCP en moins de 60 secondes. Analyse de sécurité incluse dans chaque plan.

    Product

    FeaturesSecurityPricingHow It WorksDocumentation

    Resources

    Quick StartAPI ReferenceCLI ReferenceLeaderboardBlogChangelogGitHubnpm (@smeltsec/cli)npm (@smeltsec/core)

    Company

    PrivacyTerms
    SmeltSec
    © 2026 SmeltSec. Open source CLI · Proprietary SaaS.
    PrivacyTerms