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

    From Source to Production in 60 Seconds

    Eight steps. Each takes an input, runs one action, emits one output. Point SmeltSec at a repo or OpenAPI spec; get a signed, scored, deploy-ready MCP server.

    1
    Source intake
    2
    Codebase analysis
    3
    Tool definition generation
    4
    Server code generation
    5
    Gate 1
    6
    Gate 2
    7
    Quality scoring
    8
    Attestation + deploy
    1
    STEP 1

    Source intake

    Input: GitHub repo, OpenAPI spec, or natural language

    Point SmeltSec at one of three sources. A public or private GitHub URL triggers a repo clone. An OpenAPI 3.0/3.1 document is parsed directly. A natural-language description pulls in relevant SDK docs. Output: a normalized source bundle ready for AST work.

    API Equivalent
    POST /v1/generate { source: 'github', repo: 'owner/repo' }
    Source Analysis
    ◆ Analyzing repository... 342 files, 89 functions discovered
    ◆ Tree-sitter parsing... Python AST extracted for 89 functions
    ◆ API surface mapping... 14 public endpoints, 75 internal filtered
    ✓ Route detection: Flask routes (GET: 8, POST: 4, PUT: 2)
    ✓ Auth analysis: 12/14 endpoints require @auth_required
    ✓ Ready for Gate 1 14 tool candidates identified
    2
    STEP 2

    Codebase analysis

    Input: source bundle → Tree-sitter AST

    Tree-sitter parses the bundle and emits a typed AST per file. SmeltSec walks the tree, extracts public function signatures and route handlers, and filters anything marked internal or deprecated. Output: a candidate list of callable units plus their type annotations.

    API Equivalent
    GET /v1/servers/{id}/security/gate1
    Gate 1 — Pre-Generation 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 Surface: 14 endpoints mapped, auth requirements logged
    ✓ Gate 1 Decision: PASSED — 0 blockers, 2 warnings
    3
    STEP 3

    Tool definition generation

    Input: AST candidates → typed MCP tool schemas

    An LLM pass turns each candidate into an MCP tool definition: name, description, and a strict JSON Schema for arguments and return type. Docstrings feed the descriptions; type annotations become the schema. Output: a manifest of typed tools ready to wire into a server.

    API Equivalent
    POST /v1/generate { source: 'github', repo: 'owner/repo' }
    Generation Pipeline
    ◆ Curating tools... 14 tools selected from 89 functions
    ◆ Generating descriptions... AST + docstring analysis
    ◆ Building schemas... Zod schemas from type annotations
    ◆ Generating server... FastMCP + Python 3.11
    ✓ Code patterns: Retry, circuit breaker, sanitization embedded
    ✓ Server generated 14 tools, ready for Gate 2
    4
    STEP 4

    Server code generation

    Input: tool manifest → FastMCP / TypeScript SDK server

    Each tool definition becomes a real handler. SmeltSec emits FastMCP (Python 3.11) or TypeScript SDK code, wires in retries, circuit breakers, argument sanitization, and the transport of your choice. Output: a runnable MCP server repo with pinned dependencies.

    API Equivalent
    GET /v1/servers/{id}/security/gate2
    Gate 2 — Post-Generation Scan
    ◆ MCP-Scan: 14 tools scanned — 0 poisoning, 0 hidden instructions
    ◆ Behavioral Analysis: 14/14 tools — intent matches action
    ◆ Semgrep Self-Check: 0 new vulnerabilities introduced
    ◆ Permission Verification: No escalation detected (all tools ≤ source scope)
    ✓ Gate 2 Decision: PASSED — Security Grade: A (91/100)
    5
    STEP 5

    Gate 1: security scan

    Input: generated server → SAST, secrets, CVE, poison checks

    All local. All free. Semgrep runs the SAST rules, Gitleaks scans code and git history for secrets, OSV-Scanner checks pinned dependencies against the OSV database, MCP-Scan detects tool-description poisoning. A Critical finding blocks the pipeline. Output: a signed Gate 1 report.

    API Equivalent
    POST /v1/score { manifest: '...' }
    Scoring Pipeline
    ◆ Quality Score: 87/100 (B) — 6 dimensions
    ◆ Security Score: 91/100 (A) — 5 categories
    ◆ Description: 92/100 | Schema: 88 | Naming: 95
    ◆ Overlap: 78/100 — search_docs and find_docs similar
    ✓ Auto-fix: 3 suggestions available (+12 points)
    ✓ Reports generated Quality + Security report cards
    6
    STEP 6

    Gate 2: behavioral analysis

    Input: Gate 1 report + tool manifest → LLM behavior check

    An LLM compares each tool's description against what its code actually does. Mismatches surface as behavioral drift: a tool that claims to read but also writes, a description that hides side effects, a permission it never declared. This step is paid (≈ $0.02 per server). Output: a behavioral report with Pass / Warn / Fail per tool.

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

    Quality scoring

    Input: server + reports → score across 6 dimensions

    Six dimensions, one letter grade per server: description clarity, schema completeness, naming consistency, overlap with existing tools, error surface, and observability hooks. Each dimension has a numeric score and a fix suggestion. Output: a report card (A–F) with actionable items.

    API Equivalent
    POST /v1/servers/{id}/monitor { repoUrl, branch: 'main' }
    Change Detection
    ◆ Push detected: main @ abc1234
    ◆ Diffing: api/users.py (3 functions changed)
    ! HIGH impact: get_user — parameter signature changed
    ~ MEDIUM impact: update_user — return type changed
    · LOW impact: list_users — docstring updated
    → Update proposed: Surgical patch (preserves 12 edits)
    8
    STEP 8

    Attestation + deploy

    Input: passed server → signed attestation + client configs

    SmeltSec bundles the server, both gate reports, the quality score, and an SBOM into a single attestation signed with cosign. Client configs for Claude Desktop, Cursor, VS Code, ChatGPT, and Windsurf are written in one pass by the sync daemon. Output: a signed, deployable MCP server with every tool wired into every client.

    API Equivalent
    GET /v1/servers/{id}/analytics?range=7d
    Analytics & Export
    ◆ Total calls (7d): 12,847
    ◆ Error rate: 1.2% (below 5% threshold)
    ◆ Latency 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.

    Ready to start?

    Generate your first MCP server in under 60 seconds. Security scanning included on every 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