MCP server for MariaDB vector operations
Server defines 5 tools with clear action verbs (create, list, delete, insert, search) and reasonable parameter schemas. However, significant gaps in parameter descriptions, output schema documentation, and error handling guidance reduce quality. Tool descriptions are present but brief (19-64 chars), falling below the 50-200 char LLM-optimized range. Parameter descriptions exist but lack detail on constraints, formats, and recovery paths. Output responses are unstructured strings rather than documented JSON objects, making downstream tool chaining difficult. Error handling returns raw error messages without actionable recovery guidance.
Create a vector store in the MariaDB database.
Delete a vector store in the MariaDB database.
Insert a document into a vector store.
List all vector stores in a MariaDB database.
Search a vector store for the most similar documents to a query.
Tool descriptions are 19-64 characters, well below the 50-200 char LLM-optimized baseline. Descriptions lack context on WHEN to use each tool and prerequisites.
Output schema not documented. All tools return unstructured strings (e.g., 'Vector store `X` created successfully.'). LLMs cannot extract structured data for downstream tool chaining. Expected: JSON objects with typed fields (success: bool, store_name: string, count: int, etc.).
Error responses lack recovery guidance. 'Error creating vector store: <raw error>' tells the agent nothing about whether to retry, check input, or ask the user. Should specify error category (retryable, user-fixable, fatal) and suggest next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
mariadb_search_vector_store returns unstructured string with no schema. Response should be a structured object: {results: [{document: string, metadata: object, distance: float}], total: int, k: int}. LLMs cannot parse free-text results reliably.
mariadb_insert_documents metadata parameter description says 'The metadata of the documents to insert' but lacks detail on expected structure (object or array?), validation rules, or format. Ambiguous parameter descriptions cause LLM confusion.
mariadb_delete_vector_store is destructive but has no dry-run, confirmation step, or explicit warning in description that this operation is irreversible. Description should state: 'WARNING: This permanently deletes the vector store and cannot be undone.'
mariadb_list_vector_stores returns a comma-separated string 'Vector stores: store1, store2' instead of structured JSON {stores: [string], total: int}. Unstructured output blocks downstream iteration and filtering.
No pagination support on mariadb_list_vector_stores or mariadb_search_vector_store. If a user has hundreds of vector stores or search results, all are returned in one response, risking context window explosion. Should support limit/offset or cursor-based pagination.