Griptape Vector Store Driver: Azure MongoDB

The Azure MongoDB vector store driver is the pack's answer for "my embeddings already live in MongoDB Atlas." It produces a VECTOR_STORE_DRIVER configured to talk to a specific MongoDB collection on a specific Atlas cluster, and you wire that driver into the VectorStore tool or an agent so retrieval happens against your existing database. If you're already running MongoDB Atlas - on Azure, or honestly anywhere Atlas is reachable - this lets you skip standing up a separate vector database entirely and use the collection you've got.

Same honest caveat as its AWS sibling: this is infrastructure plumbing, not a beginner node. MongoDB Atlas doesn't provision itself, and you need an Atlas cluster with an index configured for vector search before this driver is useful. The "Azure" in the name is really about where your Atlas deployment sits; from this node's perspective it just builds a mongodb+srv:// connection string and connects. If you're new to this pack's RAG story, the local vector store or Griptape Cloud knowledge base is a far friendlier first stop.

How it works

The node assembles a MongoDB connection string from env-var-named inputs - username, password, host, database - then builds an AzureMongoDbVectorStoreDriver with the collection, index, and vector path, plus the embedding driver you've attached. Note it builds the connection string itself (mongodb+srv://{user}:{pass}@{host}/{db}?...) rather than taking a full URI, so you fill in the parts, not the whole URL.

The inputs that matter

Every field is the name of an environment variable (the pack's security pattern - never paste values into the graph):

• host_env - default AZURE_MONGODB_HOST. The cluster host.
• username_env / password_env - defaults AZURE_MONGODB_USERNAME / AZURE_MONGODB_PASSWORD. Atlas credentials.
• database_name_env / collection_name_env - defaults AZURE_MONGODB_DATABASE_NAME / AZURE_MONGODB_COLLECTION_NAME. Where the vectors live.
• index_name_env - default AZURE_MONGODB_INDEX_NAME. The Atlas vector search index.
• vector_path_env - default AZURE_MONGODB_VECTOR_PATH. The field in your documents holding the vector.
• embedding_driver - optional EMBEDDING_DRIVER socket; connect it explicitly so retrieval uses the same embeddings that built your data.

One output, DRIVER (VECTOR_STORE_DRIVER), feeds a VectorStore tool or agent.

Install

Standard pack install; the real setup is Atlas-side:

cd ComfyUI/custom_nodes
git clone https://github.com/griptape-ai/ComfyUI-Griptape

or ComfyUI Manager → search "Griptape" → install → restart. Then create your Atlas cluster, collection, and a vector search index, and set the seven environment variables (or add them in the Griptape settings section).

Where people get burned

The pattern is credentials and configuration, in that order. Missing or misnamed env vars produce empty connection strings and a failed connect - the classic silent failure. The vector index must already exist in Atlas with the right name, and the vector_path must match the actual field name in your documents. And again, the embedding-driver mismatch: store with model A, query with model B, get garbage. This node rewards checking your Atlas console before touching ComfyUI; every "why is retrieval empty" story here starts with an index that isn't there or a path that's misspelled.