Jerrycan MCP

Humanity's last backend. Built for AI agents.

The AI-native Rust backend framework + generation platform. Agents design, generate, verify and package complete backends. You never write the code.

jerrycan.cc · AI-native docs · Why jerrycan exists · llms.txt

Paste this into your AI agent — Claude Code, Cursor, Codex, Windsurf, or any capable one:

Fetch https://jerrycan.cc/start and follow it to set up jerrycan and build my backend.

Rather run it yourself? One line installs the CLI, wires jerrycan into your agent, and leaves a guided runbook behind:

curl -fsSL https://jerrycan.cc/install.sh | bash -s -- --agent claude-code

Agent ids: claude-code · cursor · codex · windsurf · generic. Until the site routes ship, use the mirror: curl -fsSL https://raw.githubusercontent.com/backant-io/jerrycan/main/scripts/install.sh | bash -s -- --agent <id>

$ jerrycan new --design bookmarks.json       # describe it once
  ✓ scaffolded a crate-per-module workspace

$ jerrycan gen-tests --module bookmarks      # the test suite is generated for you
  ✓ 8 acceptance tests written

  …an agent fills in ~12 lines of obvious handler glue…

$ jerrycan --json check                      # build · clippy · audit · tests · lints
  {"ok":true,"diagnostics":[]}               # all green: safe + tested, no internals leaked

Published on crates.io, with prebuilt binaries on GitHub Releases. Early but real. Expect rough edges as it grows.

30-second agent onboarding

The intended path. One line installs the CLI, connects jerrycan to your coding agent, and leaves a guided runbook behind:

curl -fsSL https://jerrycan.cc/install.sh | bash -s -- --agent claude-code

That does three things for you:

• Installs the jerrycan binary — the CLI, and the MCP server your agent talks to. (MCP is just the standard way an agent calls an outside tool; you don't have to configure it.)

• Wires it into your agent — for Claude Code it runs claude mcp add for you and drops in the bundled jerrycan-backend skill; for Cursor / Codex / Windsurf it writes the right MCP config file.

• Runs jerrycan onboard — printing the guided runbook your agent follows: design → scaffold → generate tests → implement → check → package → deploy.

Then just ask, in plain language — "Build me a backend for …" — and the agent drives the whole loop. Point any other agent at docs/ai or jerrycan.cc/llms.txt; the docs are written to be sufficient on their own.

# Claude Code
claude mcp add jerrycan -- jerrycan mcp

// Cursor / any stdio MCP client
{ "mcpServers": { "jerrycan": { "command": "jerrycan", "args": ["mcp"] } } }

Related MCP server: Igniral MCP Server

Key features

• Agents build it, you don't. Describe the API once; jerrycan generates the workspace, a working data layer, and the tests. Handlers come out as a few lines of obvious glue.

• Secure by default. Secure response headers, body limits, strict input handling, no internals leaked in errors, #![forbid(unsafe_code)] everywhere, and stable JC#### codes that deep-link into the docs.

• Tested before it's "done". jerrycan generates the acceptance suite test-first; jerrycan check won't go green until it passes. What the generator can't derive from the contract becomes an explicit AGENT TODO in the test file, so the gaps are named instead of silent.

• Fail loud. Conflicting routes are build-time errors before serving; missing dependencies and cycles are coded errors, not mysteries.

• Multi-agent ready. Generated apps are crate-per-module workspaces with compiler-enforced boundaries, so parallel agents merge without conflicts.

• Deploy anywhere, deployed by the agent. jerrycan package produces a static binary, a hardened container image, k8s manifests, or a systemd unit, with an SBOM. jerrycan deploy render writes a deploy kit the agent executes with an API key: design file to live URL, no human in the loop.

• Docs that can't lie. Every example in the docs is a doctest executed in CI.

How it works

The agent drives one fixed loop; jerrycan does the generation and the gating:

jerrycan_design    → requirements become a validated design.json (pointed questions, not guesses)
jerrycan_scaffold  → a crate-per-module workspace, one route crate per module
jerrycan_gen_tests → failing acceptance tests, generated from the design
   (the agent implements the handler bodies, guided by the docs tools)
jerrycan_check     → build + clippy + audit + tests + jerrycan lints, machine-readable diagnostics
jerrycan_package   → hardened artifacts + SBOM, only when everything is green
jerrycan_deploy    → a deploy kit for the target platform (Render first), run by the agent

crates/
├── jerrycan          # facade + the CLI/MCP binary, apps depend on this
├── jerrycan-core     # routing, extractors, DI, modules, middleware, errors, test client
├── jerrycan-macros   # #[jerrycan::main]
├── jerrycan-db       # data layer + migrations (SeaORM)
├── jerrycan-auth     # sessions, JWT, OAuth2, guards
├── jerrycan-validate  # validation + OpenAPI
├── jerrycan-observe   # logs, /healthz, /metrics
├── jerrycan-ratelimit # rate limiting (429 JC0429)
├── jerrycan-jobs      # background jobs, cron, retries (Postgres / Redis)
├── jerrycan-storage   # object storage: design-modeled buckets, local + S3, signed URLs
└── jerrycan-realtime  # realtime: Postgres Changes + Broadcast + Presence (WebSocket)
docs/
├── ai/               # the AI-native docs, every example is a CI-run doc-test
└── contracts/        # MCP tool schemas, design.json schema, CLI UX spec

Does it actually work?

Yes, and it's measured, not asserted. A docs-only agent (given only jerrycan docs, no framework source, no fixtures) builds real backends that pass jerrycan check and serve real HTTP:

• 5/5 of the reference CRUD apps: green on the first run, zero doc gaps.

• The full multi-tenant SaaS slice: green across 6 modules + 2 background jobs, driven live over HTTP. Auth, per-tenant isolation, signed webhooks, CSV import, scoped API keys, OAuth. A negative control (breaking tenant scoping) correctly turns the gate red, so the green isn't hollow.

It's wired as an un-skippable release gate (CI + a fail-fast pre-publish block), so it can't silently regress. Full write-up: conformance/eval/results.md.

For humans

Prefer to drive it yourself, or add the framework to a Rust app directly? Get the CLI without the installer script:

cargo binstall jerrycan   # prebuilt binaries (all 4 targets, from GitHub Releases)
cargo install jerrycan    # or build the CLI from source

Add the framework to your own app, with the extensions you need:

cargo add jerrycan --features db,auth,validate,observe

A route module is Flask's Blueprints, reborn with compiler-enforced boundaries. Everything a handler needs is visible in its signature, and guards are just dependencies:

use jerrycan::prelude::*;

pub fn module() -> Module {
    Module::new("todos")
        .route("/", get(list).post(create))
        .route("/{id}", get(show).delete(remove))
        .mount("/{id}/comments", comments::module()) // subroutes nest arbitrarily
        .provide(TodoRepo::new())                    // module-scoped dependency
}

async fn list(repo: Dep<TodoRepo>) -> Result<Json<Vec<Todo>>> {
    Ok(Json(repo.all().await?))
}

async fn remove(_: Dep<Admin>, repo: Dep<TodoRepo>, Path(id): Path<i64>) -> Result<NoContent> {
    repo.delete(id).await?;            // `Dep<Admin>` is the guard: a dependency that must resolve
    Ok(NoContent)
}

Testing runs real requests in memory, no sockets, and any dependency can be faked in one line:

let t = app().into_test().override_dep(Db::fake());
assert_eq!(t.get("/todos/").await.status(), jerrycan::http::StatusCode::OK);

jerrycan stands on the Rust ecosystem you already trust, and emits plain Rust you own:

Rust · Tokio · hyper · SeaORM · serde · clippy · cargo-audit

What it's for, and what it's not

For: CRUD-shaped, multi-tenant REST APIs. The backbone of most SaaS.

Also shipping (contract v2): design-modeled object storage (storage.buckets) and realtime (Postgres Changes + Broadcast + Presence).

Not (yet): GraphQL / gRPC, edge / serverless. jerrycan runs as a normal long-lived service. We'd rather name the edges than oversell the middle.

Roadmap

The v1 plan is in the v1 design spec; the v2 roadmap is in the v2 design spec; deferred items are in the backlog.

Development

./scripts/install-hooks.sh              # one-time: fmt + clippy run on every commit
cargo test --workspace --all-features   # CI runs this, every docs example is a doc-test
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo fmt --all --check
cargo bench                             # criterion benches (routing, extraction)
cargo +nightly fuzz run <target>        # fuzz targets live in fuzz/ (outside the workspace)

The project is built docs-first and test-first: documentation examples are the executable specification. Heavy end-to-end conformance (real builds, real Postgres/Redis/MinIO) runs off the per-PR path via the manual Heavy suite workflow (.github/workflows/heavy.yml).

Sponsors

jerrycan is built by one developer and a fleet of agents. Sponsorship pays for the eval infrastructure, the deploy targets, and the time it takes to keep the gate honest.

License

Licensed under the MIT License.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be licensed under the MIT License, without any additional terms or conditions.

jerrycan.cc  ·  AI-native docs  ·  GitHub @backant-io