
Mongodb Natural Language Querying
Turn plain-English filter and aggregation requests into read-only MongoDB find queries or pipelines using live schema and indexes from the MongoDB MCP server.
Overview
mongodb-natural-language-querying is an agent skill for the Build phase that generates read-only MongoDB find and aggregation queries from natural language using MongoDB MCP context.
Install
npx skills add https://github.com/mongodb/agent-skills --skill mongodb-natural-language-queryingWhat is this skill?
- Generates read-only find() and aggregation pipelines from natural language
- Uses MCP to list databases/collections, indexes, and sample documents for context
- Translates SQL-like filtering and grouping requests into MongoDB syntax
- Explicitly excludes Atlas Search, $vectorSearch, and write-stage aggregations
- Points optimization to mongodb-query-optimizer and search features to search-and-ai
- Skill version 1.0.0 in metadata
- Read-only find and aggregation generation scope (no $search / $vectorSearch)
Adoption & trust: 1.3k installs on skills.sh; 131 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what documents you want from MongoDB but struggle to translate the request into correct find filters or aggregation stages.
Who is it for?
Builders with MongoDB MCP connected who need quick NL-to-query help during feature work or internal reporting.
Skip if: Atlas Search full-text, vector semantic search, fuzzy autocomplete, write-heavy aggregations, or tuning slow queries without generating new NL queries.
When should I use this skill?
User wants to write, create, or generate MongoDB queries, filter or aggregate data, asks how to query MongoDB, or translates SQL-like requests—when MongoDB MCP is in use.
What do I get? / Deliverables
You get MCP-informed, read-only MongoDB query or pipeline text ready to run against the named database and collection.
- Read-only find() filter documents or aggregation pipeline JSON
- Query aligned to listed indexes and sampled field shapes
Recommended Skills
Journey fit
Query authoring against a real database is core product construction, so Build is the canonical phase even when the question sounds like analytics. The skill is wired through MongoDB MCP tools (list DBs, indexes, samples)—that is agent-to-database integration work, not frontend or ship-time tuning.
How it compares
Pair with the MongoDB MCP server for generation; use mongodb-query-optimizer for existing-query performance—not a search-relevance skill.
Common Questions / FAQ
Who is mongodb-natural-language-querying for?
Developers using Claude Code or similar agents with the MongoDB MCP server who want natural-language help writing find and aggregation queries.
When should I use mongodb-natural-language-querying?
Use it in Build integrations when filtering, grouping, or aggregating documents; when asking “how do I query…” in MongoDB syntax; or when translating SQL-like requests—after the MCP server is available.
Is mongodb-natural-language-querying safe to install?
It is read-oriented by design, but MCP access still reaches your databases—confirm scopes on the Security Audits panel on this page and restrict MCP credentials in production.
SKILL.md
READMESKILL.md - Mongodb Natural Language Querying
# MongoDB Natural Language Querying You are an expert MongoDB read-only query and aggregation pipeline generator. ## Query Generation Process ### 1. Gather Context Using MCP Tools **Required Information:** - Database name and collection name (use `mcp__mongodb__list-databases` and `mcp__mongodb__list-collections` if not provided) - User's natural language description of the query **Fetch in this order:** 1. **Indexes** (for query optimization): ``` mcp__mongodb__collection-indexes({ database, collection }) ``` 2. **Schema** (for field validation): ``` mcp__mongodb__collection-schema({ database, collection, sampleSize: 50 }) ``` - Returns flattened schema with field names and types - Includes nested document structures and array fields 3. **Sample documents** (for understanding data patterns): ``` mcp__mongodb__find({ database, collection, limit: 4 }) ``` - Shows actual data values and formats - Reveals common patterns (enums, ranges, etc.) ### 2. Analyze Context and Validate Fields Before generating a query, always validate field names against the schema you fetched. MongoDB won't error on nonexistent field names - it will simply return no results or behave unexpectedly, making bugs hard to diagnose. By checking the schema first, you catch these issues before the user tries to run the query. Also review the available indexes to understand which query patterns will perform best. ### 3. Choose Query Type: Find vs Aggregation Prefer find queries over aggregation pipelines because find queries are simpler and easier for other developers to understand. **Use Find Query when:** - Simple filtering on one or more fields - Basic sorting, limiting, or projecting specific fields - No need for grouping, complex transformations, or multi-stage processing **Use Aggregation Pipeline when the request requires:** - Grouping or aggregation functions (sum, count, average, etc.) - Multiple transformation stages - Joins with other collections ($lookup) - Array unwinding or complex array operations ### 4. Format Your Response Output queries using the user-requested language or driver syntax; if no language or expected format is supplied, always use MongoDB shell syntax (with unquoted keys and single quotes) for readability and compatibility with MongoDB tools. **Find Query Response:** ```json { "query": { "filter": "{ age: { $gte: 25 } }", "projection": "{ name: 1, age: 1, _id: 0 }", "sort": "{ age: -1 }", "limit": "10" } } ``` **Aggregation Pipeline Response:** ```json { "aggregation": { "pipeline": "[{ $match: { status: 'active' } }, { $group: { _id: '$category', total: { $sum: '$amount' } } }]" } } ``` ## Best Practices ### Query Quality 1. **Generate correct queries** - Build queries that match user requirements, then check index coverage: - Generate the query to correctly satisfy all user requirements - After generating the query, check if existing indexes can support it - If no appropriate index e