Loading ToolBench
An MCP server for SqlVectorDB with support for MyScaleDB, chDB, pgvector, and Text-to-Vector SQL
This server defines 14 tools across four database engines (chDB, MyScaleDB, PostgreSQL+pgvector, text2vecsql). Strengths: tool names follow verb_noun convention (run_*, list_*, search_*), descriptions are detailed and rich with examples, all tools are READ_ONLY and well-scoped. Critical weaknesses: (1) Input schemas are not visible in the provided source code, only parameter names and descriptions are shown, no explicit JSON Schema with types; (2) Output schemas are completely undocumented, what fields do these tools return? (3) Error handling is present in implementation (timeouts, error checks) but not surfaced in tool descriptions; (4) Several tools like 'get_vector_query' appear to use LLM-generated output (natural_language_question → SQL generation), but output format is not specified. Per HARD SCORING RULES: if input schemas are not visible in source, schema score must be 0 for those tools. Average across all tools pulls overall to 52.
This prompt helps users understand how to interact with chDB and perform common operations
Get a vector query from a natural language question and table schema. IMPORTANT: Before calling this tool, you MUST translate the natural_language_question to English if it is not already in English. Find the column names that must be returned in natural_1anguage_question, and you also need to add prompts to inform the model of these column names that must be returned. This tool requires English input for optimal performance. Use this tool for natural language questions that require a vector query. You can use this tool to generate a vector query for a natural language question, and then execute the query on the database. And return the results to the user. Suitable for: - Questions that require a vector query - Questions that require a standard SQL query Best practices: - ALWAYS translate the question to English before calling this tool - Use the vector query tool for natural language questions that require a vector query - Use the standard SQL query tool for natural language questions that require a standard SQL query Use this tool when you need to generate a vector query for a natural language question. And then execute the query on the database. Example: - Can you unveil the crown jewel of our vegetarian delights, the one that has soared to the top of the sales charts from the elite circle of our most cherished categories this year?
List available MyScaleDB databases
List all tables in PostgreSQL database
Input schemas not visible in source code. Tool registrations show parameter names and descriptions only; no explicit JSON Schema type definitions are shown. Per HARD SCORING RULE, schema score must be 0 for all tools.
Output schemas are completely undocumented. No tool description specifies what fields are returned, their types, or structure. Users/LLMs cannot plan downstream tool chains or extract required data for chaining (e.g., does list_tables return table_id for downstream queries?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
List all vector columns and their dimensions across all tables. Returns detailed vector column information: - Table schema and table name - Vector column name - Vector dimensions (e.g., vector(1536) means 1536-dimensional vector) Use this tool to identify vector columns and their dimensions before creating vector indexes.
List available MyScaleDB tables in a database, including schema, comment, row count, and column count. Returns detailed table information including: - Column types (Array(Float32) indicates vector columns) - Table engine and sorting keys - Row counts and storage statistics - Column comments and constraints Use this to identify vector columns before creating vector indexes. Vector columns are typically Array(Float32) or Array(Float64) types.
This prompt helps users understand how to interact with MyScaleDB and perform operations.
This prompt helps users understand how to interact with pgvector and perform operations.
Run SQL in chDB, an in-process ClickHouse engine. chDB = In-Process ClickHouse + Direct Query via Table Functions Key Features: 1. Table Functions - Query data sources directly without import: - Local files: file('path/to/file.csv') or file('data.parquet', 'Parquet') - Remote files: url('https://example.com/data.csv', 'CSV') - S3 storage: s3('s3://bucket/path/file.csv', 'CSV') - PostgreSQL: postgresql('host:port', 'database', 'table', 'user', 'password') - MySQL: mysql('host:port', 'database', 'table', 'user', 'password') 2. Supported Formats: - CSV, TSV, JSON, JSONEachRow - Parquet, ORC, Avro 3. Best Practices: - Use LIMIT to prevent large result sets (recommend LIMIT 10 by default) - Use WHERE to filter and reduce data transfer - Use SELECT to specify columns and avoid full table scans - Multi-source JOIN: file() JOIN url() JOIN s3() - Test connection: DESCRIBE table_function(...) 4. No Data Import Required: - Query data in place - If no suitable table function exists, use Python to download to temp file and query with file()
Run a SELECT query on PostgreSQL with pgvector support. PostgreSQL + pgvector extension Available Query Functions: 1. Vector Similarity Search: - <-> : L2 distance (Euclidean) - for general vector comparison - <=> : Cosine distance - for text embeddings (recommended) - <#> : Inner product distance - for normalized vectors - Example: SELECT id, vec_col <=> '[0.1,0.2,0.3]' AS distance FROM tbl ORDER BY distance LIMIT 10 2. Full Text Search: - to_tsvector('english', text_col): Convert text to search vector - to_tsquery('search & terms'): Create search query - @@ operator: Match operation - Example: SELECT id FROM tbl WHERE to_tsvector('english', text) @@ to_tsquery('machine & learning') LIMIT 10 3. Hybrid Queries: - Combine vector search with full-text search - Example: SELECT id FROM tbl WHERE to_tsvector('english', text) @@ to_tsquery('AI') ORDER BY vec_col <=> '[...]' LIMIT 10 Best Practices: - Use LIMIT to prevent large result sets - Filter with WHERE first, then perform vector search - Combine multiple search conditions for better results
Run a standard SELECT query in a MyScaleDB database. Use this tool for regular SQL queries without vector/text search functions. For similarity search, use run_similarity_select_query instead. Suitable for: - Data filtering and aggregation: SELECT ... WHERE ... GROUP BY ... - Table joins: SELECT ... FROM t1 JOIN t2 ON ... - Statistical analysis: SELECT COUNT(*), AVG(col), SUM(col) ... - Data exploration: SELECT * FROM table LIMIT 10 Best Practices: - Always use LIMIT to prevent large result sets - Always use arraySlice to silice the vector array result to avoid massive data transfer - Use WHERE to filter data before aggregation - Use ORDER BY to sort results - Use GROUP BY for aggregation queries - Use appropriate JOIN types for multi-table queries
Run a SELECT query in a MyScaleDB database. MyScaleDB = ClickHouse + Vector Search Available Query Functions: 1. Vector Search: - distance(embedding, [0.1, 0.2, 0.3]): Calculate vector similarity - Supported metrics: Cosine, L2, IP (Inner Product) - Example: SELECT id, distance(embedding, [0.1, 0.2, 0.3]) AS dist FROM tbl ORDER BY dist LIMIT 10 2. Full Text Search: - TextSearch(text_col, 'search query'): Full text search with score - Example: SELECT id, TextSearch(text, 'machine learning') AS score FROM tbl ORDER BY score DESC LIMIT 10 3. Hybrid Search: - HybridSearch(embedding, text_col, [0.1, 0.2, 0.3], 'search query'): Combine vector and text search - Example: SELECT id, HybridSearch(embedding, text, [0.1, 0.2, 0.3], 'AI') AS score FROM tbl ORDER BY score DESC LIMIT 10 Best Practices: - Always use LIMIT to prevent large result sets - Combine filters with vector/text search for better results - Filter first, then search: WHERE category='tech' AND distance(...) < 0.5
Perform similarity search using vector embeddings. Distance Functions: - 'l2': L2/Euclidean distance (<-> operator) - for general vector comparison - 'cosine': Cosine distance (<=> operator) - for text embeddings - 'inner_product': Inner product distance (<#> operator) - for normalized vectors Note: Ensure indexes are created for vector columns for optimal performance.
Text to Vector SQL initial prompt.
Error handling not surfaced in tool descriptions. Source code shows timeout handling and error checking (e.g., in run_chdb_select_query), but tool descriptions do not explain what errors can occur, what they mean, or how LLMs should recover. Per pattern:recovery-guide, errors must guide the agent's next step.
'get_vector_query' tool generates SQL from natural language via LLM. Output format (SQL string? Structured query object?) is not documented. Tool description states 'Example: Can you unveil the crown jewel...' but does not specify the return format or what fields the LLM should extract.
Prompt tools (chdb_initial_prompt, myscaledb_initial_prompt, pgvector_initial_prompt, text_to_vec_sql_initial_prompt) have minimal or placeholder descriptions ('This prompt helps users understand...'). Descriptions should explain WHEN to call them (e.g., 'Call at session start to learn chDB syntax and best practices') and what context they provide.
Parameter 'like' and 'not_like' in list_tables use SQL LIKE patterns but descriptions do not document the pattern syntax. LLMs may not know that '%' matches any substring or '_' matches single char. Add examples: 'Pattern syntax: % = any substring, _ = single char. E.g., "user%" matches user, users, user_profile.'
Parameter 'distance_function' in search_similar_vectors lists enum values ('l2', 'cosine', 'inner_product') in description but not as a formal enum constraint. LLMs may hallucinate variants like 'l2-distance' or 'euclidean'. Add explicit enum: ["l2", "cosine", "inner_product"].
No pagination parameters visible in run_chdb_select_query, run_similarity_select_query, run_select_query, run_pgvector_select_query, or search_similar_vectors. Descriptions mention 'Use LIMIT to prevent large result sets' but tool does not enforce limits. If an LLM omits LIMIT, the query could return thousands of rows, exhausting context. Enforce a maximum result set and document it.
list_databases and list_pgvector_tables return no input parameters, so no way to filter or paginate results. If databases/tables are numerous, entire list returned, wasting tokens and risking context overflow. Add optional filter and limit parameters.
Tool composition concern: get_vector_query generates SQL from natural language, but it returns a query string that the LLM must then pass to run_similarity_select_query or run_select_query. Descriptions do not clarify which tool to use next or how to chain them. Add guidance: 'Returns a SQL query string. Pass it to run_similarity_select_query if it uses vector/text search functions, or run_select_query for standard SQL.'