Skip to main content

Anatomy of a Pack

A Worka pack is more than one source file and more than one image. It is a package of code plus platform contract.

At minimum, a pack usually contains:

  • source code for the tools and optional views
  • a worka/aip.json manifest
  • a runtime entrypoint, usually an MCP server over stdio
  • optional migrations or data assets
  • optional documentation or examples for people extending it later

The manifest​

worka/aip.json is the pack’s contract with the platform.

It tells Worka things such as:

  • the pack’s identity
  • which tools it exposes
  • which outbound domains it needs
  • which connections or auth context it expects
  • which container image or runtime entrypoint is associated with it

Without a good manifest, the pack may compile but it will not fit cleanly into the runtime.

The MCP server​

The pack’s runtime logic is normally exposed through MCP. In the Rust SDK model, that means your pack starts an MCP server and exposes named tools with structured input and output.

Those tools are what Worka discovers, authorizes, and invokes.

Optional views​

Some packs only expose tools. Others also ship views.

When a pack includes UI, the view layer should still follow the same A2UI model the rest of Worka uses. That keeps the output portable across supported clients and consistent with the platform’s control model.

Optional data and workflow behavior​

Some packs also define:

  • migrations or pack-owned tables
  • workflow templates
  • AI team member defaults
  • hook attachments or reusable workflow patterns

That is often where the most useful packs pull ahead: not only tool logic, but a clean way to plug that logic into a real workspace.