One Index, Every Editor

Two developers on your team work in the same codebase. One uses their preferred editor with an AI assistant. The other uses a different editor with a different assistant. Both tools are learning the codebase independently. Both are building context from scratch. Neither knows what the other has learned.

This is the current state of AI-assisted development. Context is fragmented by tool.

The Multi-Tool Reality

Development teams do not standardize on a single editor anymore. Personal preference matters. Some developers chose their editor years ago and see no reason to switch. Others pick tools based on specific features: one editor for its debugging experience, another for its language server, a third for its AI capabilities.

AI assistants have multiplied the surface area. An editor might have a native AI integration. A third-party extension might add another. A separate tool might run in the terminal. Each one builds its own understanding of the codebase—or more accurately, each one starts fresh every session.

The result is parallel work with disconnected context. Developer A's assistant learns patterns from a week of pair programming. Developer B's assistant has no access to that learning. They are working in the same codebase with tools that cannot share what they know.

Why Context Does Not Travel

Editor-native AI bakes context into the tool. The index lives inside the editor's data directory. The session history is stored in a proprietary format. The learning—whatever form it takes—belongs to that specific installation.

Switching tools means starting over. A developer who tries a new editor does not bring their context with them. The accumulated understanding from months of use stays behind. The new tool indexes the codebase fresh, as if no one had ever worked there before.

This is not a bug. It is a consequence of how these tools were built. Each editor integrates AI as a feature, not as a layer. The context system is part of the editor, not separate from it. There is no interface for exporting understanding or importing it into a different tool.

The situation resembles the pre-LSP era for language features. Every editor implemented its own parsing, its own autocompletion, its own go-to-definition. Then the Language Server Protocol separated the language intelligence from the editor. One language server could serve any compatible editor. The same separation has not happened for AI context—until recently.

What MCP Changes

The Model Context Protocol introduces a boundary between context and editor.

MCP defines a standard interface for context providers. A context source—an index, a knowledge base, a memory system—exposes its capabilities through the protocol. Any MCP-compatible tool can query that source. The tool does not need to know how the context is stored or computed. It only needs to speak the protocol.

This decouples the context layer from the editor layer. An index built for one tool becomes accessible to every compliant tool. The investment in context pays off across the entire toolchain, not just within a single editor.

The protocol itself is straightforward. It defines how tools discover context sources, how they query them, and how results are formatted. The complexity lives in the context providers, not in the protocol. A provider can implement sophisticated retrieval, semantic search, or structure-aware indexing. The editor only needs to know how to ask questions and interpret answers.

One Index, Multiple Consumers

The practical implication is shareable context.

A team indexes their codebase once. That index runs as a service—locally or hosted—and exposes an MCP interface. Developer A's editor queries it. Developer B's editor queries it. The terminal-based tool queries it. Different tools, same context.

This is not theoretical. It works today. An MCP context server starts, indexes the codebase, and listens for queries. Each developer configures their editor to use that server. From then on, every tool draws from the same well.

The index updates once and every consumer sees the change. A new file is added; every tool knows about it. A module is refactored; every tool's understanding updates together. There is no synchronization lag between tools because there is only one source of truth.

Cross-tool workflows become natural. A developer debugs in one editor, writes code in another, runs tests in a third. The AI assistance in each tool shares context. The question asked in the debugger informs the suggestion in the code editor. The pattern observed in the test runner appears in the autocompletion.

The Team Angle

Individual developers benefit from portable context. Teams benefit even more.

Onboarding changes when new developers inherit context. Instead of waiting for the AI assistant to learn the codebase through individual interaction, a new team member connects to the same index everyone else uses. The context accumulated from months of team activity is immediately available.

Shared patterns propagate. When the team establishes a convention—a naming pattern, an architectural approach, a preferred library—the shared index reflects it. Every developer's assistant knows the convention because every developer's assistant queries the same source.

Institutional knowledge persists. A developer leaves the team; their AI assistant's learned context disappears with their installation. But a shared index remains. The understanding built through that developer's interactions lives on in the shared context, accessible to whoever comes next.

This is particularly valuable for codebases with long histories and complex structures. The context represents collective understanding, not individual tool state. It compounds over time rather than resetting with each new hire.

What This Requires

Not every index can serve multiple editors. The architecture has to support it from the ground up.

The index must be editor-agnostic. No dependencies on a specific editor's file format, session structure, or extension API. The index stores code understanding, not editor state. It can run independently of any editor process.

The index must be queryable via MCP. This means implementing the protocol correctly: proper discovery, well-formed responses, sensible error handling. A partial or nonstandard implementation breaks interoperability.

The index must handle concurrent access. Multiple editors querying simultaneously should not corrupt state or produce inconsistent results. This is standard database discipline, but it matters more when the consumers are diverse tools with different query patterns.

The index must be deployable flexibly. Some teams want local-only indexes for security or latency reasons. Others want hosted indexes for convenience and collaboration. A good solution supports both without architectural contortion.

These requirements are achievable. They represent engineering discipline, not research problems. The question is whether tool vendors choose to meet them or continue building walled gardens.

The trend points toward openness. MCP adoption is growing. More tools are implementing compliant interfaces. The moat around editor-specific context is eroding. Developers increasingly expect their context to be theirs—portable, shareable, persistent across tools.

The future is one index, every editor. The infrastructure exists. The protocol is standardized. The only remaining question is which tools embrace it and which get left behind.