An MCP server for MonkDB that provides tools to interact with MonkDB databases
MonkDB MCP server has weak definition quality with significant gaps. Tool names are acceptable but descriptions lack depth and context. Most critically, parameter descriptions are entirely missing or minimal across tools. Input schemas exist but lack full parameter descriptions needed for LLM guidance. The server uses FastMCP/TypeScript SDK properly, but definition quality falls well below production standards. Average tool score is 38/100, this is a 'D' grade server with major issues in naming clarity, parameter documentation, and error guidance.
Describe a table's columns in MonkDB
Returns the version of MonkDB server using version() scalar function
Simple health check on MonkDB
List available MonkDB tables under monkdb schema
Run a SELECT query in a MonkDB database
Parameter descriptions are completely missing or minimal. 'run_select_query' has a parameter 'query' with description 'SELECT query to execute' (23 chars), insufficient to guide LLM. 'describe_table' has 'table_name' with description 'Name of the table to describe' (28 chars), lacks format/constraint guidance. LLMs cannot infer whether table_name accepts schema-qualified names, case sensitivity, or special characters.
Tool descriptions lack actionable context. 'run_select_query' description 'Run a SELECT query in a MonkDB database' (37 chars) does not state timeout (30s visible in code but absent from schema), does not clarify that non-SELECT queries are rejected, does not indicate what happens on timeout or query failure. 'describe_table' description 'Describe a table's columns in MonkDB' (37 chars) does not specify the output structure (which fields are returned) or whether schema qualification is required.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Error responses do not guide LLM recovery. Code shows queries that violate the 'SELECT-only' constraint return {'status': 'error', 'message': '...'} but description never mentions this rule. On timeout, agent sees 'Query timed out after 30 seconds' with no retry guidance or pagination suggestion. No distinction between retryable errors (timeout) vs. fatal errors (syntax error). LLM cannot decide whether to retry, adjust parameters, or escalate.
Parameter 'query' in 'run_select_query' accepts unbounded free-form SQL strings with no validation schema or format constraints visible. LLMs can be prompted to inject malicious queries or non-SELECT statements (despite runtime validation). No enum, pattern, maxLength, or other constraints in schema. Accepts any string; filtering happens at execution time.
Output schemas are not documented in tool definitions. 'list_tables' returns [{'table_name': ...}] but the schema does not specify this structure. 'run_select_query' returns variable-schema results (depends on the query) with no guidance on the output format. 'describe_table' output structure is not shown. LLMs cannot predict the response format or plan downstream calls.
No pagination support for 'list_tables'. If MonkDB schema contains hundreds or thousands of tables, the response will be unbounded and may exhaust context or cause LLM reasoning degradation. No limit parameter, no offset/cursor, no total_count or next_cursor field. Violates mxe:enforce-result-limits (cap results at 20-50 with pagination).
Tool naming lacks distinctive clarity where multiple tools operate on the same resource. 'get_server_version' and 'health_check' are both diagnostic, but their names do not indicate the difference. Is 'health_check' checking connectivity, or is 'get_server_version' checking availability? Names should disambiguate (e.g. 'check_monkdb_health' vs 'get_monkdb_server_version').