Definition

What is a Context Container?

Last updated

A portable, shareable unit of organized context (documents, data, and structured information) made accessible to AI agents through MCP tools.

A context container is the fundamental unit of Wire. Each container holds files or agent-written entries, processes them into an AI-optimized format, and exposes the whole thing through a standard set of MCP tools. Containers are private by default, work across any MCP-compatible AI tool, and can be shared with teammates without duplicating content into every tool that needs it.

  • Holds files, structured data, or agent-written entries in a single scoped workspace.
  • Every container ships with six MCP tools: wire_explore, wire_search, wire_navigate, wire_write, wire_delete, wire_analyze.
  • Private by default; shareable with teammates via organization roles.
  • Portable across AI tools: one container connects to Claude, Cursor, Cline, and anything else MCP-compatible.
  • Isolated per container, so agent A's context doesn't leak into agent B's.

How context containers work

Each container is a stateful, isolated workspace with its own data store. Containers don’t share state with each other, which is what makes scoping per project or per team practical. The flow:

  1. Create. A container gets a unique MCP endpoint and an empty store.
  2. Add content. Upload files through the app or REST API, or let agents write entries directly via wire_write.
  3. Process. In the background, Wire chunks long documents, extracts entities and relationships, and generates embeddings. Tools stay available while processing runs.
  4. Serve. The container’s MCP server exposes five standard tools plus any custom tools generated from the content. Connect any MCP client and start querying.

The unit of scope is the container. You can have many of them: one per project, per team, per client. Handing an agent a specific container means it sees that container’s context and nothing else.

Why scoped containers matter

AI agents need context, but they rarely need all your context on every task. Broad access is the most common source of both quality problems and security incidents. Three properties of containers address this:

  • Scope per task. A customer-support agent gets a container of support content, not your entire company knowledge base. A coding agent gets a repo container, not your HR docs.
  • Portability. The same container works across Claude, Cursor, Cline, and any other MCP-compatible tool. You don’t re-upload or reconfigure per tool.
  • Shareability. Teams can share a container without each person rebuilding a personal context store.

The combination is what “context as a service” means in practice: a durable, composable unit of context that follows the user across tools.

Common misconceptions about context containers

  • “A container is just a folder of files.” Files are the raw input. Wire processes them into structured records with embeddings, entity extraction, and relationship edges. The tools your agent calls query the processed layer, not the raw files.
  • “More containers means more duplication.” The opposite, usually. Scoping containers per project or team prevents the “one giant index of everything” problem where retrieval surfaces irrelevant content from unrelated work.
  • “Containers are locked into Wire.” They’re exposed through MCP, which is an open standard. An agent that reads from a Wire container today will work identically against any other MCP server you point it at tomorrow.

Context containers and Wire

This is Wire’s primary abstraction; everything else is built around containers. The pricing model, the app UI, the MCP server, the REST API, the billing system, and the RBAC all revolve around containers as the unit of ownership. If you’re evaluating Wire, the fastest path is to spin up an ephemeral container (no account needed), upload a few files, and call wire_search from your AI tool of choice.

FAQ

Frequently asked questions

Common questions about Context Container.

How is a context container different from a vector database?
A vector database is one implementation detail of retrieval. A context container is a user-facing unit of scope: you upload files, an agent writes entries, content is processed into structured records with embeddings, and everything is exposed through MCP tools. The container model assumes you want many small scoped workspaces rather than one giant index.
What can I put in a container?
Any file type (PDFs, docs, spreadsheets, code, markdown), plus structured entries agents write directly through wire_write. Wire processes uploaded files: chunks long documents, extracts entities and relationships, generates embeddings, and builds a queryable index.
Can multiple agents share a container?
Yes. Any MCP client pointed at the container's endpoint can call its tools. This is how teams give a single agent access to shared company context, or how multiple specialized agents coordinate through a common workspace.
How are containers private by default?
Each container is scoped to your organization. Access is enforced via OAuth 2.1 and Wire's role-based access control (owner / admin / member). Containers can be shared with specific teammates, but they aren't exposed publicly unless you explicitly list them in the public directory.
What's the difference between a container and an MCP server?
An MCP server is the protocol layer. A container is the content layer: the files, entries, and generated tools that your MCP server exposes. Every Wire container runs its own MCP server automatically, so you get the server for free when you create the container.

Put context into practice

Create your first context container and connect it to your AI tools in minutes.

Create Your First Container