Skip to main content
Glama
Sign In
CoraDB MCP Server

CoraDB MCP Server

Official
by apsisware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Describe the CoraDB schema

describe_schema
Read-only

Reads live database catalog metadata for tables, views, vertex and edge tables, including columns, keys and indexes, to inspect schema before writing queries. Describe a single object when needed.

Instructions

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 object for a single table. Read this before writing queries.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "database": "<database>"
    },
    "name": "describe_schema"
  }
}

Input Schema

NameRequiredDescriptionDefault
hostNoCoraDB broker host. Default: localhost.
portNoCoraDB broker port. Default: 33000.
userNoDatabase user. Default: dba.
formatNotext (default): CREATE-like summary. json: the CoraDB schema document.
objectNoOne table, view, vertex or edge table to describe (case-insensitive).
refreshNoRead the catalog again instead of using the copy kept for a few minutes.
databaseYesThe database to open.
passwordNoPassword of that user. Default: empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two things the annotations do not: results come from the live catalog rather than a static snapshot, and visibility is scoped to the given user's permissions. Caching behavior is left to the `refresh` parameter description rather than stated here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the scope statement comes before the single-object hint and the read-before-querying advice. The first sentence is a dense noun phrase with several parentheticals, which slightly hurts scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only introspection tool with eight parameters and no output schema, the description covers the important ground: what is returned, whose visibility applies, and when to call it. The absence of an output schema is partly offset by the explicit enumeration of returned fields, though the two output formats are only explained in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains every one of the eight parameters, including the text/json format choice and the catalog-cache refresh. The description only reinforces `object` as the single-table selector. Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates exactly what the tool returns: tables, views, vertex tables and edge tables with columns, keys and indexes, read from the live catalog. That is specific enough to separate it from execute_select or execute_sql. It loses a point only because the leading clause is a bare noun phrase rather than a verb-plus-resource statement of what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Read this before writing queries" gives a clear triggering condition, and "Give `object` for a single table" distinguishes the narrow call from the whole-database call. No sibling tool is named as an alternative and there is no explicit when-not guidance, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools