Loading ToolBench
MCP Server exposing tools to interact with a MariaDB database. Manages the database connection pool with support for vector embeddings, SQL queries, and database administration.
The MariaDB MCP server exposes a single tool (create_vector_store) with reasonable naming and description, but significant schema and parameter documentation gaps limit its quality. The tool name follows verb-noun convention (good), but the input schema lacks proper parameter type declarations and descriptions in the visible schema object. The tool description is comprehensive (228 chars, within 194-char baseline), but parameter descriptions are incomplete or missing from the schema structure. The server is built on fastmcp and includes production considerations (SSL support, CORS, connection pooling), but the tooling layer itself shows moderate quality issues typical of community servers.
Creates a table which stores embeddings. Creates a new vector store (table) with a predefined schema if it doesn't already exist. It first checks if the database exists, creating it if necessary. Then, it checks if the table exists; if so, it reports that. Otherwise, it creates the table with id, document, embedding (VECTOR type), and metadata (JSON) columns. A VECTOR INDEX is created on the embedding column.
Schema parameter types and descriptions not fully visible in source code. While the function signature shows parameter names and types (database_name: str, vector_store_name: str, model_name: Optional[str], distance_function: Optional[str]), the JSON Schema object passed to FastMCP tool registration is not shown.
Parameter 'distance_function' lacks enum constraint. Description states 'euclidean or cosine' as free-form text rather than as a formal enum. This invites hallucinated values ('manhattan', 'squared', etc.). Should declare as enum: ["euclidean", "cosine"].
Parameter 'model_name' description states 'defaults to service default' but does not clarify what values are accepted, what the actual default is, or how to discover valid model names. Ambiguous parameter guidance violates param-description pattern.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No documented output schema. The tool returns a dict but the response structure (success/failure, created_table_id, status message, error details) is not declared. LLMs cannot predict downstream field availability.
No error handling guidance. Tool description does not explain error cases: what happens if database already exists, table already exists, invalid distance function, embedding service unavailable, or database connection fails. Recovery paths not documented.
Missing dry-run or confirmation pattern. The tool creates database objects (irreversible). No mention of a --dry-run flag or confirmation step. Agents should be able to preview what will be created before execution.