# Container Best Practices

This guide covers best practices for organizing context containers.

## Planning Your Containers

Before creating containers, consider:

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

## Container Names

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.

### Naming Best Practices

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).

## Organization Patterns

### By Project

One container per project or product:

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

### By Team

One container per team or department:

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

### By Content Type

One container per content type:

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

## Common Mistakes

### Too Many Small Containers

**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.

### Too Few Large Containers

**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.

## Next Steps

- [Supported File Types](/reference/file-types/) - What you can upload
- [Tools Reference](/reference/tools/) - Tool reference
- [Roles & Permissions](/reference/roles/) - Manage your team