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

    Vom Quellcode zur Produktion in 60 Sekunden

    Acht Schritte. Jeder nimmt eine Eingabe, führt eine Aktion aus, erzeugt eine Ausgabe. Zeigen Sie SmeltSec auf ein Repo oder OpenAPI-Spec; erhalten Sie einen signierten, bewerteten, einsatzbereiten MCP-Server.

    1
    Quellen-Aufnahme
    2
    Codebasis-Analyse
    3
    Tool-Definitionen generieren
    4
    Server-Code-Generierung
    5
    Gate 1
    6
    Gate 2
    7
    Qualitätsbewertung
    8
    Attestierung + Deploy
    1
    SCHRITT 1

    Quellen-Aufnahme

    Eingabe: GitHub-Repo, OpenAPI-Spec oder natürliche Sprache

    Zeigen Sie SmeltSec auf eine von drei Quellen. Eine öffentliche oder private GitHub-URL löst einen Klon aus. Ein OpenAPI-3.0/3.1-Dokument wird direkt geparst. Eine natürlichsprachliche Beschreibung zieht passende SDK-Docs heran. Ausgabe: ein normalisiertes Quell-Bundle, bereit für die AST-Arbeit.

    API-Äquivalent
    POST /v1/generate { source: 'github', repo: 'owner/repo' }
    Quellcode-Analyse
    ◆ Repository wird analysiert... 342 files, 89 functions discovered
    ◆ Tree-sitter-Parsing... Python AST extracted for 89 functions
    ◆ API-Oberfläche wird kartiert... 14 public endpoints, 75 internal filtered
    ✓ Routenerkennung: Flask routes (GET: 8, POST: 4, PUT: 2)
    ✓ Auth-Analyse: 12/14 endpoints require @auth_required
    ✓ Bereit für Gate 1 14 tool candidates identified
    2
    SCHRITT 2

    Codebasis-Analyse

    Eingabe: Quell-Bundle → Tree-sitter AST

    Tree-sitter parst das Bundle und erzeugt pro Datei einen typisierten AST. SmeltSec durchläuft den Baum, extrahiert öffentliche Funktionssignaturen und Route-Handler, und filtert alles, was als intern oder veraltet markiert ist. Ausgabe: eine Kandidatenliste aufrufbarer Einheiten mit Typannotationen.

    API-Äquivalent
    GET /v1/servers/{id}/security/gate1
    Gate 1 — Vor-Generierungs-Scan
    ◆ 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)
    ◆ API-Oberfläche: 14 endpoints mapped, auth requirements logged
    ✓ Gate 1 Entscheidung: PASSED — 0 blockers, 2 warnings
    3
    SCHRITT 3

    Tool-Definitionen generieren

    Eingabe: AST-Kandidaten → typisierte MCP-Tool-Schemas

    Ein LLM-Pass verwandelt jeden Kandidaten in eine MCP-Tool-Definition: Name, Beschreibung und ein striktes JSON Schema für Argumente und Rückgabetyp. Docstrings speisen die Beschreibungen; Typannotationen werden zum Schema. Ausgabe: ein Manifest typisierter Tools, bereit für die Verdrahtung in einen Server.

    API-Äquivalent
    POST /v1/generate { source: 'github', repo: 'owner/repo' }
    Generierungs-Pipeline
    ◆ Tools werden kuratiert... 14 tools selected from 89 functions
    ◆ Beschreibungen werden generiert... AST + docstring analysis
    ◆ Schemas werden erstellt... Zod schemas from type annotations
    ◆ Server wird generiert... FastMCP + Python 3.11
    ✓ Code-Muster: Retry, circuit breaker, sanitization embedded
    ✓ Server generiert 14 tools, ready for Gate 2
    4
    SCHRITT 4

    Server-Code-Generierung

    Eingabe: Tool-Manifest → FastMCP- / TypeScript-SDK-Server

    Jede Tool-Definition wird zu einem echten Handler. SmeltSec emittiert FastMCP-Code (Python 3.11) oder TypeScript-SDK-Code, verdrahtet Retries, Circuit Breaker, Argument-Sanitization und das gewünschte Transport. Ausgabe: ein lauffähiges MCP-Server-Repo mit fixierten Abhängigkeiten.

    API-Äquivalent
    GET /v1/servers/{id}/security/gate2
    Gate 2 — Nach-Generierungs-Scan
    ◆ MCP-Scan: 14 tools scanned — 0 poisoning, 0 hidden instructions
    ◆ Verhaltensanalyse: 14/14 tools — intent matches action
    ◆ Semgrep Self-Check: 0 new vulnerabilities introduced
    ◆ Berechtigungsverifizierung: No escalation detected (all tools ≤ source scope)
    ✓ Gate 2 Entscheidung: PASSED — Security Grade: A (91/100)
    5
    SCHRITT 5

    Gate 1: Sicherheitsscan

    Eingabe: generierter Server → SAST, Secrets, CVE, Poisoning-Checks

    Alles lokal. Alles kostenlos. Semgrep führt die SAST-Regeln aus, Gitleaks scannt Code und Git-Historie nach Secrets, OSV-Scanner prüft gepinnte Abhängigkeiten gegen die OSV-Datenbank, MCP-Scan erkennt Tool-Description-Poisoning. Ein Critical-Befund stoppt die Pipeline. Ausgabe: ein signierter Gate-1-Report.

    API-Äquivalent
    POST /v1/score { manifest: '...' }
    Bewertungs-Pipeline
    ◆ Qualitätsbewertung: 87/100 (B) — 6 dimensions
    ◆ Sicherheitsbewertung: 91/100 (A) — 5 categories
    ◆ Beschreibung: 92/100 | Schema: 88 | Naming: 95
    ◆ Überschneidung: 78/100 — search_docs and find_docs similar
    ✓ Auto-Fix: 3 suggestions available (+12 points)
    ✓ Berichte erstellt Quality + Security report cards
    6
    SCHRITT 6

    Gate 2: Verhaltensanalyse

    Eingabe: Gate-1-Report + Manifest → LLM-Verhaltensprüfung

    Ein LLM vergleicht die Beschreibung jedes Tools mit dem, was sein Code tatsächlich tut. Abweichungen erscheinen als Verhaltensdrift: ein Tool, das zu lesen behauptet, aber auch schreibt, eine Beschreibung, die Seiteneffekte verbirgt, eine Berechtigung, die nie deklariert wurde. Dieser Schritt ist kostenpflichtig (≈ 0,02 $ pro Server). Ausgabe: ein Verhaltensreport mit Pass / Warn / Fail pro Tool.

    API-Äquivalent
    GET /v1/servers/{id}/config?client=claude_desktop
    Deploy & Konfiguration
    ✓ 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
    ◆ Daemon: running — auto-sync on changes
    7
    SCHRITT 7

    Qualitätsbewertung

    Eingabe: Server + Reports → Bewertung über 6 Dimensionen

    Sechs Dimensionen, eine Note pro Server: Beschreibungs-Klarheit, Schema-Vollständigkeit, Namens-Konsistenz, Überlappung mit bestehenden Tools, Fehlerfläche, Observability-Hooks. Jede Dimension hat einen numerischen Score und einen Fix-Vorschlag. Ausgabe: eine Bewertungskarte (A–F) mit konkreten Aufgaben.

    API-Äquivalent
    POST /v1/servers/{id}/monitor { repoUrl, branch: 'main' }
    Änderungserkennung
    ◆ Push erkannt: main @ abc1234
    ◆ Vergleiche: api/users.py (3 functions changed)
    ! HOHER Einfluss: get_user — parameter signature changed
    ~ MITTLERER Einfluss: update_user — return type changed
    · GERINGER Einfluss: list_users — docstring updated
    → Update vorgeschlagen: Surgical patch (preserves 12 edits)
    8
    SCHRITT 8

    Attestierung + Deploy

    Eingabe: bestandener Server → signierte Attestierung + Client-Configs

    SmeltSec bündelt Server, beide Gate-Reports, den Qualitätsscore und ein SBOM in eine mit cosign signierte Attestierung. Client-Configs für Claude Desktop, Cursor, VS Code, ChatGPT und Windsurf werden vom Sync-Daemon in einem Durchgang geschrieben. Ausgabe: ein signierter, deploybarer MCP-Server, mit jedem Tool in jeden Client verdrahtet.

    API-Äquivalent
    GET /v1/servers/{id}/analytics?range=7d
    Analyse & Export
    ◆ Gesamtaufrufe (7T): 12,847
    ◆ Fehlerrate: 1.2% (below 5% threshold)
    ◆ Latenz 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.

    Bereit anzufangen?

    Generieren Sie Ihren ersten MCP-Server in weniger als 60 Sekunden. Sicherheitsscan in jedem Plan enthalten.

    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