CoraDB MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CORADB_HOST | No | Broker host for calls that give none. | localhost |
| CORADB_PORT | No | Broker port for calls that give none. | 33000 |
| CORADB_MAX_ROWS | No | Rows per SELECT when the call does not say. | 200 |
| CORADB_DATABASES | No | Databases a call may name, comma-separated; * for any. | * |
| CORADB_SCHEMA_TTL_MS | No | How long a schema read from the catalog is kept. | 600000 |
| CORADB_MAX_CELL_CHARS | No | Longer strings in a cell are cut. | 20000 |
| CORADB_MAX_ROWS_LIMIT | No | Most rows a call may ask for. | 5000 |
| CORADB_MAX_STATEMENTS | No | Most statements in one call. | 50 |
| CORADB_MAX_TIMEOUT_MS | No | Longest time limit a call may ask for. | 600000 |
| CORADB_WORKSPACE_MODE | No | Change mode: write, dryrun or off. Sets whether database changes can be made. | write |
| CORADB_CALL_TIMEOUT_MS | No | A call's time limit when it gives none; 0 for none. | 120000 |
| CORADB_QUERY_TIMEOUT_MS | No | Server-side limit per statement when the call has no limit. | 60000 |
| CORADB_CONNECT_TIMEOUT_MS | No | How long to wait for the broker. | 5000 |
| CORADB_MAX_RESPONSE_CHARS | No | Rows beyond this size are left out of a reply. | 200000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Tools for CoraDB, a relational + graph database: tables are queried with SQL, vertex and edge tables with SELECT … FROM MATCH (a:vertex)-[e:edge]->(b:vertex). Every call names its database; host, port, user and password are optional (defaults localhost:33000, user dba, empty password). Nothing is kept between calls. Start with describe_schema. Use execute_select to run SELECTs and explain_query to see a plan without running anything. execute_sql runs other statements and commits them when all succeed; pass dryRun: true to try without saving. Several statements can be sent in one call, separated by semicolons.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| connection_infoA | Log in to a CoraDB database and report the login used (never the password), the engine version and this server's settings. Use it to check that a database is reachable with a given login. |
| describe_schemaA | The tables, views, vertex (node) tables and edge tables of a database with their columns, keys and indexes, read from the live catalog as the given user sees it. Give |
| execute_selectA | Run one SELECT, or several separated by ;, and return the columns (name, type, precision, scale) and rows exactly as the engine returns them. Works for relational SQL and graph queries (SELECT … FROM MATCH …). Each statement is compiled first and refused unless it is a SELECT; nothing is ever committed. Statements run in order and the first error stops the script. |
| execute_sqlA | Run any statements — INSERT, UPDATE, DELETE, MERGE, CREATE, ALTER, DROP, SELECT … — one or several separated by ;, in order, in one transaction. If every statement succeeds, the changes are committed; if any fails, nothing is saved. dryRun: true runs everything and then rolls it back, to see what would change. Returns the rows of each SELECT and the number of rows each other statement changed. COMMIT and ROLLBACK statements are refused: the call controls the transaction. Serial increments (AUTO_INCREMENT, NEXT_VALUE) are not undone by a rollback. |
| explain_queryA | The plan the CoraDB optimizer chooses for a SELECT (or for each SELECT of a script separated by ;), without running it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct activity: connection verification, schema introspection, read-only querying, mutating/DDL execution, and plan inspection. The only potential overlap is that execute_sql can also run SELECTs, but its description explicitly frames it as the transactional read-write path while execute_select is the guarded read-only path. Boundaries are clear enough that misselection is unlikely.
Four tools follow a clean verb_noun snake_case pattern (describe_schema, execute_select, execute_sql, explain_query). connection_info breaks the pattern as a noun phrase, a minor deviation but still unambiguous and readable.
Five tools is a tight, well-scoped surface for a database MCP: connect, inspect, read, write, explain. Nothing feels redundant or missing at the count level.
The lifecycle is well covered: reachability check, live catalog introspection, read queries, transactional writes/DDL with dry-run, and plan explanation. Minor gaps exist around multi-database enumeration/switching and any explicit result-pagination or cancellation path, but agents can work around these.