Meridian

Get Database Schema

database_schema_get

Read-only

Returns the structure of the managed database attached to an environment: every table with its columns (name, type, nullable, default, and key flags) and its indexes (name, columns, unique). Read this before writing a migration, model or query, since the live schema is what the last applied migration produced and the repository may not match it.

STRUCTURE ONLY. This tool never reads table rows. Meridian does have a SQL console for that, but it is deliberately not exposed here: running queries would put merchant data into this conversation. Use the dashboard when you need to read data.

Requires the environment to have a READY database add-on; environments without one report a clear error. For a developer's own isolated database, use dev_database_get instead.

Takes the app_id from apps_list and the environment_id from environments_list.

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": {
      "app_id": "<app_id>",
      "environment_id": "<environment_id>"
    },
    "name": "database_schema_get"
  }
}

Input Schema

Name	Required	Description
`app_id`	Yes	The app uuid returned by `apps_list`.
`environment_id`	Yes	The environment whose database to describe, from `environments_list`.
`organization_id`	No	An organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses that only structure is returned and rows are never read, that the result reflects the last applied migration rather than the repository, and that a READY database add-on is required or a clear error is returned. That is exactly the extra context annotations cannot carry.

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?

Front-loaded with the return shape, then a capped 'STRUCTURE ONLY' guardrail, then prerequisites and alternatives — a sensible order with little filler. The final sentence duplicates parameter guidance already present in the schema, which is the only real waste.

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

Completeness5/5

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

With no output schema, the description carries the burden of describing return values and does so concretely. For a read-only introspection tool it covers prerequisites, failure mode, scope limits, and sibling alternatives, leaving nothing an agent needs before calling it.

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 coverage is 100%, so the baseline is 3; the description's closing sentence on sourcing `app_id` from `apps_list` and `environment_id` from `environments_list` merely restates the schema descriptions. The optional `organization_id` parameter, including its slug-resolution behavior, is not addressed in the description at all.

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

Purpose5/5

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

States a specific verb and resource ('Returns the structure of the managed database attached to an environment') and then enumerates the returned shape — tables with columns and key flags, plus indexes with name/columns/unique. It is clearly distinguishable from `dev_database_get` (developer's isolated DB) and from the SQL console it explicitly declines to be.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('read this before writing a migration, model or query'), an explicit exclusion with the reason ('STRUCTURE ONLY... running queries would put merchant data into this conversation. Use the dashboard when you need to read data'), and a named alternative for the isolated-database case (`dev_database_get`).

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

All Meridian tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?