TL;DR

Mastra's MongoDB vector store today requires you to generate embeddings yourself before writing or querying. MongoDB now offers Automated Embedding, where the database vectorizes your text with a Voyage AI model automatically. Extend MongoDBVector so a user can index a text field and search with a plain query string — reusing the existing documents parameter and query methods — with no embedding provider, model wiring, or dimension bookkeeping in app code.

Context

What Mastra is. Mastra is a TypeScript agent framework. For retrieval-augmented generation (RAG) it ships pluggable vector stores — databases that store text alongside its numeric embedding (a vector that captures meaning) so you can search by semantic similarity rather than keywords. @mastra/mongodb is the MongoDB implementation (class MongoDBVector).

Key concepts.

• Embedding: turning text into a vector using a model. Similar meanings produce nearby vectors.
• Client-side embedding (today): your application calls an embedding model, then hands the resulting vectors to the store. Mastra already documents this with Voyage models via the @mastra/voyageai package.
• Automated Embedding (the feature): an Atlas Vector Search index of type autoEmbed that names a text field and a Voyage AI model. MongoDB generates embeddings server-side — when documents are written and when a query string arrives — so vectors never travel through app code. This is the server-side counterpart of the Voyage pairing Mastra already documents. Models available: voyage-4 (recommended), voyage-4-large, voyage-4-lite, voyage-code-3.

The problem. With MongoDBVector today, createIndex requires a dimension, upsert requires precomputed vectors, and query requires a precomputed queryVector (it rejects a request without one). Every write must first call an embedding provider, and every read must embed the query first. That means extra dependencies, extra latency to manage, and a model/dimension contract the user maintains by hand. Automated Embedding removes all of that, but Mastra has no way to create an autoEmbed index or query by text, so the capability is currently unreachable from Mastra.

Desired User Experience

Reuse existing API surface wherever possible. The documents parameter already exists on upsert; the string query parameter already exists on textQuery/hybridQuery. Names marked illustrative below are the implementer's to finalize.

Before — client-side embeddings (current, documented behavior):

import { MongoDBVector } from '@mastra/mongodb';
import { voyage } from '@mastra/voyageai';
import { embed, embedMany } from 'ai';

const store = new MongoDBVector({ id: 'rag', uri: process.env.MONGODB_URI!, dbName: 'rag' });

// You declare the vector dimensions yourself (must match the model).
await store.createIndex({ indexName: 'movies', dimension: 1024, metric: 'cosine' });

// You must embed text before writing, and pass the vectors in.
const { embeddings } = await embedMany({
  model: voyage.embedding('voyage-3.5'),
  values: ['A lonely astronaut...', 'A heist in Paris...'],
});
await store.upsert({
  indexName: 'movies',
  vectors: embeddings,
  documents: ['A lonely astronaut...', 'A heist in Paris...'],
  metadata: [{ title: 'Solaris' }, { title: 'Heist' }],
});

// You must embed the query before searching.
const { embedding } = await embed({ model: voyage.embedding('voyage-3.5'), value: 'space opera' });
const results = await store.query({ indexName: 'movies', queryVector: embedding, topK: 5 });

After — MongoDB Automated Embedding (desired):

import { MongoDBVector } from '@mastra/mongodb';

const store = new MongoDBVector({ id: 'rag', uri: process.env.MONGODB_URI!, dbName: 'rag' });

// Name the text field + Voyage model. No `dimension` (derived from the model), no embedding provider.
await store.createIndex({
  indexName: 'movies',
  autoEmbed: { path: 'fullplot', model: 'voyage-4' }, // illustrative shape
});

// Reuse the existing `documents` parameter — no `vectors`. MongoDB embeds server-side at index-time.
await store.upsert({
  indexName: 'movies',
  documents: ['A lonely astronaut...', 'A heist in Paris...'],
  metadata: [{ title: 'Solaris' }, { title: 'Heist' }],
});

// Search with a string — MongoDB embeds it server-side at query-time with the same model.
// (`query()` today takes a numeric `queryVector`; the implementer reconciles the string-query
//  parameter name with the existing `query` string used by textQuery()/hybridQuery().)
const results = await store.query({ indexName: 'movies', queryText: 'space opera', topK: 5 });

Task

Goals

• Let a Mastra user run semantic search on MongoDB without generating or managing embeddings themselves.
• Reuse existing MongoDBVector surface (documents on upsert, the string-query convention) so the new path feels native, not bolted on.
• Expose the Voyage model choice and relevant autoEmbed index options through createIndex.

Where

• Vector store: stores/mongodb/src/vector/index.ts
• Reference docs (live): https://mastra.ai/reference/vectors/mongodb — source docs/.../reference/vectors/mongodb.mdx

Acceptance Criteria

• [ ] A user can create an autoEmbed index through MongoDBVector, choosing the text field to embed and one of the supported Voyage models (voyage-4, voyage-4-large, voyage-4-lite, voyage-code-3), without supplying a dimension.
• [ ] All relevant autoEmbed index options are configurable through Mastra (Voyage model, and any options MongoDB exposes such as output dimensions and filter fields for pre-filtering).
• [ ] A user can write documents as plain text via the existing documents parameter (no vectors), and MongoDB generates the embeddings server-side.
• [ ] A user can query an autoEmbed index by passing a query string, with MongoDB embedding it server-side (no queryVector required); the string-query parameter name is consistent with the existing query/queryVector conventions.
• [ ] Existing client-side behavior (dimension + vectors + queryVector) continues to work unchanged — Automated Embedding is additive.
• [ ] describeIndex() reports a sensible dimension for an autoEmbed index (the model's output dimension).
• [ ] Light unit/integration tests cover autoEmbed index creation, text upsert, and text query, and the existing MongoDBVector test suite still passes.
• [ ] A follow-up documentation ticket is created to update the reference and integration pages to show Automated Embedding with MongoDBVector.

Additional Context

• Automated Embedding is currently a MongoDB Preview feature; self-managed deployments require MongoDB 8.0+, and Atlas dedicated clusters (M10+) require storage auto-scaling because generated embeddings are stored on the cluster. The index becomes queryable asynchronously — the existing waitForIndexReady() should cover the build/sync wait.
• Memory semanticRecall is out of scope for this ticket. The docs wire MongoDBVector into Memory alongside a separate embedder; memory's recall path embeds the query client-side and passes a queryVector, so it will not automatically use Automated Embedding. Making Memory skip the client-side embedder when the store embeds server-side is a separate follow-up.

References

• MongoDB Automated Embedding overview: https://www.mongodb.com/docs/atlas/atlas-vector-search/automated-embedding/
• Indexing fields for Vector Search (autoEmbed / filter types): https://www.mongodb.com/docs/atlas/atlas-vector-search/vector-search-type/