Build with MCP
Build and deploy an Imperal app straight from your AI client (Claude Code, Cursor, Codex) using imperal-mcp — a local MCP server that turns any LLM into an Imperal app builder.
imperal-mcp is a local MCP server that lets your AI client — Claude Code, Cursor, Codex, or any Model Context Protocol host — build, validate, deploy, and read-operate an Imperal app for you. Your client's own model authors the app; the server gives it the rails (the IR spec, the UI catalog, real examples) and the safe verbs (validate, smoke, deploy).
It's the fastest way to go from "I want an app that…" to a deployed Imperal app without hand-writing the SDK — and it's complementary to the SDK path: the app it produces is the same declarative IR the SDK speaks.
Install
pip install imperal-mcp # or: pipx install imperal-mcp
imperal-mcp login # opens your browser to authorize — no API key to copyThen point your MCP client at it. For example, .mcp.json:
{
"mcpServers": {
"imperal": { "command": "imperal-mcp" }
}
}No token lives in the config — imperal-mcp login handles authorization in your browser and stores the session locally.
What your model gets
When the server is connected, your client's model is armed with:
- Resources —
imperal://ir-spec(what an app is),imperal://ui-catalog(everyui.*primitive), andimperal://examples(working apps to learn from). - A guided prompt —
build_imperal_app, which walks the model through authoring a correct app.
Tools
Build
validate_ir(app_ir)— fully local, no network: checks the IR envelope and every step against the schemas.smoke_ir(app_ir, function, args)— runs a function in an isolated sandbox so the model can see real output before deploying.deploy_ir(app_ir, app_id)— deploys the app (creates it the first time, updates it on re-deploy).
Operate (read-only, PII-masked)
list_apps,get_app— discover what's deployed.run_read_tool(app_id, function, args)— runs only tools declaredaction_type: "read"; write/destructive tools are refused, and unknown tools fail closed.
The IR a step speaks
A declarative step is op + args{kind, data} — for example:
{ "id": "s1", "op": "store.create", "args": { "kind": "link", "data": { "url": "…" } } }The envelope carries ir_version, an app (id + version + title + capabilities), and functions (each with name, action_type, params_schema, return_schema, and a declarative impl.steps). The full vocabulary lives in the SDK Reference.
The flow
- Arm — your client reads the IR spec + UI catalog + examples.
- Author — the model writes the app IR.
- Validate → Smoke — catch shape and behavior issues locally before anything ships.
- Deploy —
deploy_irpublishes it; the app's title and description become its identity across the panel and the Marketplace. - Operate — read tools let the model inspect live data (writes always go through the user's own confirmation in the app).
Versions
Release notes live in the project's CHANGELOG.md (GitHub imperalcloud/imperal-mcp):
- 0.3.0 — a deterministic build→deploy door: auto-registers you as a developer, get-or-creates the app, retries only transient errors, and reports truthful results.
- 0.2.0 — browser login (
imperal-mcp login). - 0.1.0 — build · validate · smoke · deploy · read-operate.
Your First Real Extension
Build your first real Webbee extension — typed params, multiple handlers, panels, and audit — deployed end to end through the Imperal Developer Portal.
Why this is the first ICNLI AI Cloud OS
A precise definition of the first ICNLI AI Cloud OS: the six kernel-property test, named-alternative scoring, and a falsifiable claim of priority by ICNLI.