Build a scripture app
from a prompt.

Scripture App Builder is the SIL-built tool translation teams have used since 2015 to package Paratext projects, MP3 audio, timing files, color schemes, splash screens and signing keys into a real Android or iOS application — shipped to the playstore, sideloaded, or carried into a village on a microSD card. It's free, it's astonishing, and it has hundreds of opinionated settings the agent has no business pretending to know. The MCP server here doesn't pretend to know any of that either. It exposes filesystem-shaped IO, content-addressed job submission, and gets out of the way.

The opinions live next door, in a canon repository served by oddkit. The agent talks to one MCP — this one. The docs(query) tool proxies canon retrieval upstream, so the agent's loop is ask docs · understand · act · observe across a single connection.

"I am very grateful for the app of our culture, the New Testament app. I love this because God gives each ethnic group their culture to value." Pastor Arcesio · Guahibo people group · on a Scripture app in his language

Both demo payloads are checked-in smoke fixtures from the repo's smoke/ directory and have already been built once, so they cache-hit and return instantly — zero container CPU. The artifact card below is a real R2-served APK.

The MCP server's docs(query) tool searches the project's canon — prose articles, build manifests, app.json schemas, and governance documents that give an agent enough context to drive Scripture App Builder. Type a question; see the actual answer plus the canon URIs that backed it.

A signed Android build for a New Testament with audio takes 8–25 minutes. iOS with provisioning takes longer. Synchronous tools collide with every chat-shaped surface in existence. So the protocol is async: submit returns immediately, status is pollable, cancellation is honored.

// returns immediately
{
  job_id: "4a17b9c2…",
  payload_hash: "4a17b9c2…",
  cached: true,
  predicted_artifact_url: "…/r2/…/apk",
  predicted_size_mb: 148
}

{
  state: "succeeded",
  stage: 7/7,
  current: "sign-and-zipalign",
  warnings: 3,
  errors: [],
  human_summary:
    "Built. Signed. 148 MB."
}

{
  ok: true,
  was_running: false,
  cancelled_at: "2026-05-01T13:24:00Z",
  partial_artifacts: [
    "…/staging/manifest.xml"
  ]
}

// note · the three async tools are the build contract. The full live surface also exposes docs(query) for canon retrieval (proxied to oddkit) and telemetry_public · telemetry_policy · telemetry_schema for transparency (seven tools total). README and page enumerations drift — the deploy is authoritative. Ask tools/list against /mcp for the current surface.

Every tool call against appbuilder.klappy.dev writes one structural data point to appbuilder_telemetry. Same data the maintainer sees, queried over MCP from this page in your browser, right now. Identify yourself with an x-appbuilder-client header and you'll appear on the consumer leaderboard below.

Vodka architecture — coined in the broader klappy canon and applied across oddkit, ptxprint-mcp, and now this server — says each MCP server holds opinions about exactly one concern. The AppBuilder server holds none about translation craft, font resolution, or app design — only about subprocess lifecycle, content-addressed caching, signing-key vault access, and sandboxed file IO. Domain knowledge lives next door, in canon. Agents see one MCP; AppBuilder delegates canon retrieval to oddkit upstream when serving docs().