feat: Adds the atlas-list-performance-advisor base tool #528
Conversation
kylelai1
changed the title
| .array(z.nativeEnum(PerformanceAdvisorOperation)) | ||
| .describe("Operations to list performance advisor recommendations"), | ||
| since: z.number().describe("Date to list slow query logs since").optional(), | ||
| processId: z.string().describe("Process ID to list slow query logs").optional(), |
There was a problem hiding this comment.
Is this something we expect the LLM to know how to get? As far as I can tell, you get it by calling atlas processes list but we don't have any tools that mirror that behavior in the MCP server.
| operations: z | ||
| .array(z.nativeEnum(PerformanceAdvisorOperation)) | ||
| .describe("Operations to list performance advisor recommendations"), | ||
| since: z.number().describe("Date to list slow query logs since").optional(), |
There was a problem hiding this comment.
Should this be z.date instead? Does the LLM do a good job at converting dates to unix epoch?
|
|
||
| // If operations is empty, get all performance advisor recommendations | ||
| // Otherwise, get only the specified operations | ||
| const operationsToExecute = operations.length === 0 ? Object.values(PerformanceAdvisorOperation) : operations; |
There was a problem hiding this comment.
Should we mark operations as optional and provide a default instead? Right now there's nothing to hint to the LLM it could provide an empty array here.
|
|
||
| try { | ||
| if (operationsToExecute.includes(PerformanceAdvisorOperation.SUGGESTED_INDEXES)) { | ||
| const { suggestedIndexes } = await getSuggestedIndexes(this.session.apiClient, projectId, clusterName); |
There was a problem hiding this comment.
This is probably not super critical, but right now, all of these async operations are evaluated sequentially, which means that we need to wait for one to finish before starting the next one. Instead, it would be a good idea to run them in parallel.
| return { | ||
| content: [{ type: "text", text: JSON.stringify(data, null, 2) }], | ||
| }; |
There was a problem hiding this comment.
We should wrap the response in formatUntrustedData to avoid injection attacks where someone creates a slow query that contains llm instructions. Also, it might be helpful to give hints to the llm what the different fields in the json data represent and how those can be used.
|
|
||
| interface DropIndexSuggestion { | ||
| accessCount?: number; | ||
| index?: Array<{ [key: string]: 1 | -1 }>; |
There was a problem hiding this comment.
Is this type definition true? Would PA not suggest dropping geo or text indexes?
There was a problem hiding this comment.
Let me look into this. I used the Open API definitions for the Atlas Admin API, but it would be weird to not include text indexes to drop suggestions for example (same for index creation suggestions!)
| type SchemaTriggerType = | ||
| | "PERCENT_QUERIES_USE_LOOKUP" | ||
| | "NUMBER_OF_QUERIES_USE_LOOKUP" | ||
| | "DOCS_CONTAIN_UNBOUNDED_ARRAY" | ||
| | "NUMBER_OF_NAMESPACES" | ||
| | "DOC_SIZE_TOO_LARGE" | ||
| | "NUM_INDEXES" | ||
| | "QUERIES_CONTAIN_CASE_INSENSITIVE_REGEX"; | ||
|
|
||
| type SchemaRecommedationType = | ||
| | "REDUCE_LOOKUP_OPS" | ||
| | "AVOID_UNBOUNDED_ARRAY" | ||
| | "REDUCE_DOCUMENT_SIZE" | ||
| | "REMOVE_UNNECESSARY_INDEXES" | ||
| | "REDUCE_NUMBER_OF_NAMESPACES" | ||
| | "OPTIMIZE_CASE_INSENSITIVE_REGEX_QUERIES" | ||
| | "OPTIMIZE_TEXT_QUERIES"; |
There was a problem hiding this comment.
Do we need to translate these to something the LLM would have an easier time interpreting?
Proposed changes
This PR adds the atlas-list-performance-advisor tool to the MCP server, which retrieves the following performance advisor recommendations from the admin API: index suggestions, drop index suggestions, schema suggestions, slow query logs.
This PR merges the changes into the atlas-list-performance-advisor-tool branch.
Testing
Checklist