Why MCPForge
AI agents (ChatGPT, Claude, Cursor, and custom ones) are shifting from talking to doing — they act across your apps for you. For an agent to use an app, that app needs an MCP server (Model Context Protocol) — a universal "socket" any agent can plug into.
Soon every product will be asked "does this work with my AI agent?" — the way "do you have a mobile app?" became mandatory a decade ago. But building an MCP server today means stitching together five different tools: one to convert your API, one to test it, one to scan it for security, one to run it, one to monetize it.
MCPForge is the one tool that does the whole job — the neutral developer experience that runs the full lifecycle on top of the open standard.
npx mcp-forge init ./openapi.json # inspect: tools, auth, a security glance
npx mcp-forge scan ./openapi.json # low-noise security scan (CI-friendly)
npx mcp-forge test ./openapi.json # call every tool live + report what works
npx mcp-forge monetize ./openapi.json # emit a usage meter + pricing you own
npx mcp-forge generate ./openapi.json # emit a deployable MCP server you own
npx mcp-forge serve ./openapi.json # run it locally + watch every agent call
Universal by design
- Any API in — any OpenAPI 2 (Swagger) or 3.x spec, JSON or YAML, file or URL. The API can be written in any language or framework (Node, Python, Go, Rails, PHP…). MCPForge only reads the spec.
- Any agent out — it emits a standard MCP server, so it works with any MCP client.
- No lock-in —
generatewrites files you own and can deploy anywhere.
Install
npm install -g @muhammad-adil-code/mcp-forge
# …or run without installing:
npx @muhammad-adil-code/mcp-forge <command> <spec>
After a global install, the
mcpforgecommand is available directly.
Commands
| Command | What it does |
|---|---|
init / inspect |
Parse the spec → show the tools, declared auth, and a quick security glance. |
scan |
Full security scan, low-noise by design — only flags what's genuinely actionable (writes with no auth, path-traversal params, unschematized bodies, a broad delete surface). Exits non-zero on high, so it drops straight into CI. |
test |
Call every tool against the live API with sample inputs synthesized from each tool's schema, then report what actually works: pass, need-auth, expected 4xx, server-error, unreachable. Read-only by default (mutations skipped unless --write). Exits non-zero on real failures — CI-friendly. |
monetize |
Emit a drop-in usage meter + pricing you own — classifies each tool by cost weight (reads cheap, writes standard, delete/bulk heavy), suggests per-call prices and tiers, and writes a zero-dependency meter.mjs that counts credits, enforces quotas, and emits billing events you forward to Stripe / a ledger / a webhook. --rate <cents>. |
generate |
Emit a self-contained MCP server (server.mjs + model + package.json + README). You own it; deploy anywhere. --out ./dir. |
serve |
Run the MCP server locally over stdio and log every tool call live, so you can point an agent at it and watch what it does. --auth "Bearer …". |
Flags
--base-url <url> Override the API base URL (if the spec omits it)
--out <dir> Output directory for `generate` (default ./mcp-server)
--auth <value> Authorization header forwarded to the backing API
--write Include write ops (POST/PUT/PATCH/DELETE) when running `test`
--rate <cents> Cents per credit for `monetize` (default 2)
--help, --version
Example
$ mcpforge init https://petstore3.swagger.io/api/v3/openapi.json
MF MCPForge › Swagger Petstore - OpenAPI 3.0 1.0.27
base url https://petstore3.swagger.io/api/v3
tools 19
auth petstore_auth, api_key
● addPet POST /pet
● getPetById GET /pet/{petId}
…
⚠ security 1 medium (run: mcpforge scan …)
$ mcpforge generate ./openapi.json --out ./my-mcp
$ cd my-mcp && npm install && npm start
# → a real, protocol-compliant MCP server your agent can connect to.
The security scan is deliberately quiet
Existing MCP scanners are notorious for ~78% false positives — pattern-matching that fires on everything. MCPForge takes the opposite stance: few, true findings, each with a concrete fix. It flags what actually matters when you hand an API to an autonomous agent — writes with no auth, path/file params that enable traversal or SSRF, request bodies with no schema, and a dangerously broad delete surface.
How it works
any OpenAPI spec ──▶ normalized tool model ──▶ ┌─ generate (deployable server)
(any language) (one clean shape) ├─ scan (low-noise security)
├─ test (live tool verification)
├─ monetize (usage meter + pricing)
├─ serve (run + inspect calls)
└─ …future stages plug in here
Every stage operates on one normalized model, never the raw spec — which is what keeps each stage simple and the input universal. New stages (test, deploy, monetize) plug into the same model.
Roadmap
-
init·scan·test·monetize·generate·serve— the full lifecycle, verified end-to-end - Hosted dashboard (single pane of glass for tools, tests, findings, call logs)
- One-command deploy
- Managed billing integrations (Stripe metered billing out of the box)
Contributing
Issues and PRs welcome. New scanner rules and language/spec edge-cases are especially useful — the goal is a tool that "just works" on any real-world API.
License
MIT Muhammad Adil
