Skip to content

Container Best Practices

This guide covers best practices for organizing context containers.

Before creating containers, consider:

  1. Scope - What context belongs together?
  2. Access - Who needs access to this context?

When you create a container, Wire assigns a random placeholder name like “Prancing Zebra”. You can change the name and description anytime in Container Settings.

Good container names are concise (1-3 words), describe the content domain, and slugify well (no special characters).

Examples: “Product Docs”, “Customer Support”, “Sales Playbook”

The container name is used for MCP client naming (e.g., “wire-product-docs”) but does NOT affect the MCP URL (which uses the container ID).

One container per project or product:

my-org/
├── web-app-docs
├── mobile-app-docs
└── api-specs

One container per team or department:

my-org/
├── engineering
├── design
└── customer-success

One container per content type:

my-org/
├── documentation
├── research-data
└── meeting-notes

Problem: Creating a container for each document.

Solution: Group related documents in one container. With too many small containers, relationships between data aren’t discovered across containers, so your agent has to build that context at query time.

Problem: Putting everything in one container.

Solution: Separate by topic or access needs. Purpose-driven containers offer better context and more relevant search results, making it easier for your agent to execute and saving tokens.