mongodb-query-optimizer — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited mongodb-query-optimizer (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Invoke only when the user wants:
Do not invoke for routine query authoring unless the user has requested help with optimization, slow queries, or indexing.
If the user wants to examine slow queries, or is looking for general performance suggestions (not regarding any particular query):
If Atlas MCP Server for Atlas is not configured or you don’t have enough information to run atlas-get-performance-advisor against the correct cluster, tell the user that general performance analysis requires Atlas MCP Server configuration with API credentials, and suggest they configure it or ask about a specific query instead.
If the user is asking about a particular query:
Then make an optimization suggestion based on collected information and MongoDB best practices and examples from reference files. Prefer creating an index that fully covers the query if possible. If you cannot use MongoDB MCP Server then still try to make a suggestion.
How to invoke. Call the MongoDB MCP server with the exact tool name as toolName and a single arguments object as arguments. Do not pass the tool name as an option, query param, or nested key; pass it as the MCP tool name and the parameters as the arguments object. Full MCP Server tool reference: MongoDB MCP Server Tools.
Database tools (when the MCP cluster connection works):
| Tool name (exact) | Arguments object |
|---|---|
collection-indexes | { "database": "<db>", "collection": "<coll>" } — both required strings. |
explain | { "database": "<db>", "collection": "<coll>", "method": [ { "name": "find", "arguments": { "filter": {...}, "sort": {...}, "limit": N } } ], "verbosity": "executionStats" }. method is an array of one object: name is "find", "aggregate", or "count"; arguments holds that method's params (e.g. find: filter, sort, limit; aggregate: pipeline; count: query). Optional verbosity: "queryPlanner" (default), "executionStats", "queryPlannerExtended", "allPlansExecution". |
find | { "database": "<db>", "collection": "<coll>", "filter": {...}, "projection": {...}, "sort": {...}, "limit": N } — database, collection, and filter are required. Optional: projection, sort, limit. |
Atlas tools (when Atlas API credentials are configured):
| Tool name (exact) | Arguments object |
|---|---|
atlas-list-projects | {} or { "orgId": "<24-char hex>" }. Returns projects with their IDs; use to get projectId for Performance Advisor. |
atlas-get-performance-advisor | Required: "projectId" (24-character hex string), "clusterName" (string, 1–64 chars, alphanumeric/underscore/dash). Optional: "operations" — array of strings from "suggestedIndexes", "dropIndexSuggestions", "slowQueryLogs", "schemaSuggestions" (request only what you need); for slowQueryLogs only: "since" (ISO 8601 date-time), "namespaces" (array of "db.coll" strings). |
For a user question, try to fetch information from both the connection string and Atlas API related to the query you are optimizing.
Typical flow: call collection-indexes → explain → find (sample doc).
classicIndexes (each has name, key) to see if the query can already use an existing index."queryPlanner" mode first to check for COLLSCAN. If the query uses an index or the collection is very small, run again with "executionStats" (10-second timeout) to get docs scanned vs. returned.If you need a project ID, call atlas-list-projects first. Then call atlas-get-performance-advisor with only the operations you need:
| Operation value | Use when |
|---|---|
slowQueryLogs | Fetching slow queries—prioritize by slowest and most frequent. Optional: namespaces to scope to a collection; since for a time window. |
suggestedIndexes | Fetching cluster index recommendations |
dropIndexSuggestions | User asks what to remove or reduce index overhead |
schemaSuggestions | User asks for schema/query-structure advice alongside indexes |
Do not pass the MCP tool name as an operations value—operations is a separate argument listing what data to fetch.
User: "Why is this query slow? db.orders.find({status: 'shipped', region: 'US'}).sort({date: -1})"
If MCP db connection is configured and the database + collection names are known, run steps 1–3. Otherwise skip to step 4.
collection-indexes with database=store, collection=orders{_id: 1}, {status: 1}, {date: -1}explain with method=find, filter={status: 'shipped', region: 'US'}, sort={date: -1}, verbosity=queryPlanner and executionStats{status: 1} index, then in-memory SORT, totalKeysExamined: 50000, nReturned: 100find with limit=1 to fetch a sample document to impute the schema.If MCP Atlas connection is configured, run step 4. Otherwise skip to step 5.
store, collection=orders in the past 24 hours{status: 1, region: 1, date: -1} following ESR (two equality fields, then sort). This eliminates in-memory sort and improves selectivity by filtering on both status and region.If the MongoDB MCP server is not set up, follow best indexing practices.
User: "Can you help with optimizing slow queries on my cluster?”
{status: 1, region: 1, date: -1} on the db.orders collection to optimize queries such as find({status: 'shipped', region: 'US'}).sort({date: -1})Examine all performance advisor output as well as slow query logs. Provide information on what is being improved and why, and focus on suggestions that have the potential for greatest impact (e.g., indexes that affect the most queries, or queries that have the worst performance).
Before beginning diagnosis and recommendation, load reference files.
Always load:
references/core-indexing-principles.mdreferences/antipattern-examples.mdConditionally load these files:
references/aggregation-optimization.mdreferences/update-query-examples.md for oplog-efficient updates and common update anti-patterns~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.