mongodb-natural-language-querying

MongoDB Natural Language Querying generates read-only MongoDB find queries and aggregation pipelines from natural-language descriptions, grounded in real collection schema context and sample documents. It is meant to be used whenever a user asks to write, create, or generate MongoDB queries, wants to filter, query, aggregate, group, or find documents, asks how to express something in MongoDB syntax, or wants a SQL-like request translated to MongoDB. It explicitly excludes Atlas Search, vector or semantic search, fuzzy matching, autocomplete, and relevance scoring (handled by search-and-ai), analysis or optimization of existing queries (handled by mongodb-query-optimizer), and any pipeline with write operations. It requires the MongoDB MCP server.

The generation process first gathers context with MCP tools, listing databases and collections when needed, then fetching indexes for optimization, the flattened schema with a sample size for field validation, and a few sample documents with a small limit to understand data patterns. Field names are validated against the fetched schema before a query is generated, because MongoDB does not error on nonexistent fields and instead silently returns no results. The skill then chooses between a find query and an aggregation pipeline, preferring find for simple filtering, sorting, limiting, or projection, and using aggregation for grouping, multi-stage transformation, joins via $lookup, or complex array operations. Responses are formatted in the requested language or driver syntax, defaulting to MongoDB shell syntax.

Best-practice guidance is detailed. For query quality it covers index coverage, avoiding $where and unindexed $text, sparing use of $expr, removing redundant operators such as needless $exists, projecting only needed fields, and choosing correct comparison, logical, and array operators, including efficient non-empty-array and length checks with $elemMatch and $size. For aggregation it advises filtering early with $match, projecting at the end, limiting after sort, keeping $match and $sort index-friendly, and optimizing $lookup. Error prevention emphasizes validating field references, dot notation for nested fields, escaping regex, matching data types, and the GeoJSON convention of longitude before latitude. Schema and sample-document analysis guidance rounds out how it infers types, patterns, nested structures, and special types.