cubrid-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CUBRID_HOST | Yes | Hostname of the CUBRID server | |
| CUBRID_PORT | No | Port number (default: 33000) | 33000 |
| CUBRID_USER | Yes | CUBRID username with SELECT grants | |
| CUBRID_DATABASE | Yes | Name of the CUBRID database | |
| CUBRID_PASSWORD | Yes | Password for the CUBRID user | |
| CUBRID_MCP_WRITE | No | Enable write mode (default: 0) | 0 |
| CUBRID_CONNECTIONS | No | Comma-separated list of additional connection names (optional) | |
| CUBRID_MCP_MAX_ROWS | No | Max rows returned by execute_query (default: 1000) | 1000 |
| CUBRID_MCP_READONLY | No | Enforce read-only SQL whitelist (default: 1) | 1 |
| CUBRID_MCP_AUDIT_LOG | No | Enable audit logging (default: 0) | 0 |
| CUBRID_MCP_MAX_CHARS | No | Max characters in query output (default: 4000) | 4000 |
| CUBRID_MCP_QUERY_TIMEOUT | No | Socket read timeout in seconds (default: 30) | 30 |
| CUBRID_MCP_MAX_SQL_LENGTH | No | Max length of submitted SQL (default: 65536) | 65536 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| all_table_namesB | Return every user table in the connected CUBRID database. |
| filter_table_namesA | Return user tables whose name contains |
| schema_definitionsB | Return column metadata for |
| describe_tableA | Return full metadata for |
| list_indexesC | Return indexes for CUBRID supports index hints: USE INDEX (idx_name), FORCE INDEX, USING INDEX. See cubrid://guide/performance for hint usage. |
| explain_queryA | Return CUBRID's execution plan/trace for a CUBRID uses SHOW TRACE (not standard EXPLAIN). Look for SEQ SCAN in the output — it indicates a full table scan that may benefit from an index. See cubrid://guide/performance for interpretation tips. |
| table_row_countsA | Return |
| list_serialsC | Return CUBRID SERIAL sequences with current value, increment, and bounds. |
| list_class_hierarchyC | Return CUBRID CLASS inheritance relationships (all classes or one class). |
| execute_queryA | Execute a read-only SQL statement and return rows, truncated if large. CUBRID SQL notes: prefer LIMIT n OFFSET m (comma form also works); no RETURNING clause; collection types (SET, MULTISET, SEQUENCE) may appear in results — see cubrid://guide/types for interpretation. |
| health_checkB | Check database connectivity on demand and report server status. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| summarize_table | Guide an LLM to summarize a single table using read-only tools. |
| explain_query | Guide an LLM to obtain and interpret a query's execution plan. |
| inspect_schema | Guide an LLM to build a high-level overview of the whole schema. |
| find_index_candidates | Guide an LLM to review a table's indexing for potential gaps. |
| optimize_query | Analyze a query's execution plan and suggest CUBRID-specific optimizations. |
| migrate_from_mysql | Convert a MySQL query to valid CUBRID SQL. |
| explore_unknown_db | Systematically explore an unfamiliar CUBRID database. |
| safe_data_analysis | Answer a data question using only read-only queries. |
| write_cubrid_sql | Generate valid CUBRID SQL from a natural language request. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| cubrid-schema-index | Whole-schema index: every user table with its per-table resource URI. |
| cubrid-agent-guide | Comprehensive guide for LLM agents working with CUBRID: SQL dialect, types, safety, performance, tool selection. |
| cubrid-sql-dialect-guide | CUBRID SQL syntax differences from MySQL/PostgreSQL: LIMIT, SHOW TRACE, reserved words, date functions. |
| cubrid-types-guide | CUBRID data type guide: collection types (SET, MULTISET, SEQUENCE), ENUM, JSON, and Python type mapping. |
| cubrid-performance-guide | CUBRID performance optimization: reading SHOW TRACE output, index strategies, query anti-patterns. |
| cubrid-collections-guide | Deep dive on CUBRID collection types: SET, MULTISET, SEQUENCE usage, querying, indexing, and common pitfalls. |
TDQS
Scored across 11 tools
Each tool has a distinct primary purpose, but schema_definitions and describe_table overlap on column metadata, and describe_table also overlaps with list_indexes on index information. Agents could initially confuse schema_definitions with describe_table, though the descriptions clarify the difference.
Names are readable and mostly snake_case, but conventions are mixed: verb-led names (filter_table_names, describe_table, list_indexes, execute_query) coexist with noun-led names (all_table_names, schema_definitions, table_row_counts, health_check). A uniform verb_noun pattern would improve predictability.
Eleven tools is well within the ideal range for a database introspection server. Each tool addresses a distinct need—discovery, schema, indexes, query planning, execution, and health—without feeling bloated or sparse.
The surface covers table discovery, schema/index metadata, row counts, serials, class hierarchy, query execution, and plan tracing—strong coverage for read-only CUBRID introspection. Minor gaps like foreign-key metadata or object-level DDL are absent but can be worked around via execute_query.