Containers

A container is a brand or product grouping over capabilities. One container, many capabilities — usually one per HTTP endpoint of that brand.

Without containers:

eats.dimenzuri.book-room
eats.dimenzuri.cancel-booking
eats.dimenzuri.checkin
eats.dimenzuri.room-service

…appears in the registry as four independent rows. Agents have to mentally cluster them by slug prefix.

With a container:

Container: Dimenzuri  (verified: dimenzuri.example.com)
  ├─ dimenzuri.book-room
  ├─ dimenzuri.cancel-booking
  ├─ dimenzuri.checkin
  └─ dimenzuri.room-service

…agents see one branded entity with a description, logo, website, and a verified domain badge. Discovery improves, abuse drops.

Anatomy

1
{
2
  "id": "ctr_...",
3
  "slug": "dimenzuri",
4
  "name": "Dimenzuri",
5
  "description": "A Kenyan hotel chain offering booking, room service, and concierge endpoints.",
6
  "logo_url": "https://dimenzurihotels.example/logo.png",
7
  "website_url": "https://dimenzurihotels.example",
8
  "owner_account_id": "acc_...",
9
  "status": "active",
10
  "claimed_domain": "dimenzuri.example.com",
11
  "domain_verified_at": "2026-05-22T09:14:00.000Z"
12
}

claimed_domain + domain_verified_at are present once the owner has proven control via DNS (see Domain verification).

When to use a container vs leave a capability standalone

• Use a container if you operate ≥ 2 capabilities under the same brand or product.
• Skip it for one-off capabilities, hobby endpoints, or experiments.

Containers are optional — ungrouped capabilities still work fine and remain discoverable via GET /v1/capabilities.

Domain verification

The strongest signal a container’s owner truly represents a brand is DNS control: only dimenzuri.example.com’s owner can create a TXT record under that domain.

Verification flow

1
POST /v1/capability-containers/{id}/domain/claim
2
{ "domain": "dimenzuri.example.com" }

1
{
2
  "claim": {
3
    "verification_record_host": "_lipafy.dimenzuri.example.com",
4
    "verification_record_value": "lipafy-verify=<token>",
5
    "verified": false
6
  }
7
}

Type:  TXT
Name:  _lipafy.dimenzuri.example.com
Value: lipafy-verify=<token-from-claim>
TTL:   300

1
POST /v1/capability-containers/{id}/domain/verify

What verification doesn’t do (yet)

• It does NOT yet enforce that capability slugs match the verified domain. Today you can have a verified domain dimenzuri.example.com but slugs called pizza.delivery. A future hardening pass will require the slug’s domain segment to match.
• It does NOT prove the legal entity behind the domain. DNS control ≠ trademark ownership. Use the admin review process (Apply for a public capability) for the trademark layer.

API endpoints

MCP tools

For agents using the Model Context Protocol:

Agents that want to find capabilities by brand should prefer list_containers → get_container → execute_capability over the flat list.

Related

• Capabilities — the underlying primitive containers group.
• Apply for a public capability — the human-reviewed listing path that complements DNS verification.