Tracker for epic #87 item 7 — multi-cartridge wave.
Scope
Four cartridges, all in the same domain (vector storage + RAG memory):
Why one issue covers four
The four share a domain shape (vector index → upsert → query → delete + collection management) and likely share most of the manifest/tool surface. Worth designing the operation taxonomy once across all four, then implementing per-provider. The cartridge architecture lets each ship independently once the shared manifest pattern is set.
Surface
Per cartridge, ~7 operations: `authenticate`, `list_collections`, `create_collection`, `upsert`, `query` (similarity search), `delete`, `delete_collection`.
A single bridge tool `boj_vector` (mirroring `boj_search`) dispatches via `{operation, provider, collection, vectors|query|ids, params}`. Same shape as the just-shipped `search-mcp` in PR #99.
Composition with existing cartridges
Implementation plan
Each provider as a sibling PR:
- `feat/item-7a-pinecone-mcp` — Pinecone, simplest API; landed first as the shape-setting reference
- `feat/item-7b-qdrant-mcp` — Qdrant, popular self-host option
- `feat/item-7c-weaviate-mcp` — Weaviate, hybrid (vector + keyword) search story
- `feat/item-7d-chromadb-mcp` — Chroma, embedded option, last because it adds embedded-storage complexity
~1 day per cartridge for the bridge surface + manifest + offline-menu wiring (mirroring the search-mcp pattern). Backend dispatch deferred per the cartridge-architecture norm.
Dependencies / non-dependencies
- Not blocked on item 14 (HTTP transport) — these are pure HTTP-API cartridges, work on stdio fine
- Pairs cleanly with item 9 (multi-modal) for vision-RAG (image embeddings)
- Independent of items 11 / 12 (formal verification campaigns)
Out of scope
- Local-only vector stores (FAISS, hnswlib) — these are libraries, not gateways; bare `ml-mcp` could expose them if needed but it's a different cartridge shape
- Embedding generation — that lives in `ml-mcp` (Hugging Face) or a dedicated embeddings cartridge, not in vector-DB cartridges
Exit criteria
Close when all 4 cartridges have manifest + bridge surface + offline-menu entry, mirroring the search-mcp pattern. Backend implementation tracked separately per cartridge.
Tracker for epic #87 item 7 — multi-cartridge wave.
Scope
Four cartridges, all in the same domain (vector storage + RAG memory):
Why one issue covers four
The four share a domain shape (vector index → upsert → query → delete + collection management) and likely share most of the manifest/tool surface. Worth designing the operation taxonomy once across all four, then implementing per-provider. The cartridge architecture lets each ship independently once the shared manifest pattern is set.
Surface
Per cartridge, ~7 operations: `authenticate`, `list_collections`, `create_collection`, `upsert`, `query` (similarity search), `delete`, `delete_collection`.
A single bridge tool `boj_vector` (mirroring `boj_search`) dispatches via `{operation, provider, collection, vectors|query|ids, params}`. Same shape as the just-shipped `search-mcp` in PR #99.
Composition with existing cartridges
Implementation plan
Each provider as a sibling PR:
~1 day per cartridge for the bridge surface + manifest + offline-menu wiring (mirroring the search-mcp pattern). Backend dispatch deferred per the cartridge-architecture norm.
Dependencies / non-dependencies
Out of scope
Exit criteria
Close when all 4 cartridges have manifest + bridge surface + offline-menu entry, mirroring the search-mcp pattern. Backend implementation tracked separately per cartridge.