Skip to main content

Chapter 2: The Anatomy of an AI Pack

TL;DR​

A pack is a directory with a conventional structure. The key components are:

my-cool-pack/
├── aip.json         # Manifest: identity, capabilities, views, and tool exposure.
├── src/             # Pack code (single MCP server).
│   └── lib.rs
├── assets/          # (Optional) Static images, icons, etc.
├── locales/         # (Optional) i18n translation files.
└── sql/             # (Optional) Database migrations for pack‑owned schema.

At its core, an AI Pack is just a folder with a specific, conventional structure. The Worka Host Application reads this folder to understand what the pack does, how to run it, and how to display it to the user.

A pack is built on three fundamental pillars.

Pillar 1: The User Interface (A2UI)​

This is what the user sees. Packs define views using A2UI, a structured UI schema. Views are produced either:

  • Statically via init_views (recommended for default pages), or
  • Dynamically by returning worka_ui in MCP responses.

The host renders these views safely and predictably, without running arbitrary frontend code.

Pillar 2: The Backend Logic (MCP Tools)​

This is where your pack’s capabilities live. Each pack exposes a single MCP server that defines tools, resources, and optional workflows. Tools are strictly typed and schema‑validated.

Tools can be called by UI events, orchestration workflows, or agents. Examples include: create_ticket, send_message, search_properties, or fetch_report.

Worka provides SDKs that implement MCP and A2UI builders in multiple languages, with Rust as the reference SDK.

Pillar 3: The Manifest (aip.json)​

The aip.json file is the most important file in your pack. It is the "ID card" or "contract" that describes your pack to the Worka Host. It's a simple JSON file that tells the Host everything it needs to know:

  • Identity: Unique name, tenant, and version.
  • Presentation: Display name, description, icon.
  • Views: Static view definitions (if provided).
  • Tools & Permissions: Capabilities required at runtime.
  • Dependencies: Other packs this pack can call.

The Host reads this file to know how to build, run, and display your pack, and to enforce its security sandbox.