Meridian

Reset Developer Database

dev_database_reset

Destructive

IRREVERSIBLY drops and recreates the CALLING user's own developer database schema for an app: every table and row is destroyed and replaced with an empty schema. The underlying MySQL user/credentials are unaffected. Only the data is wiped. Equivalent to meridian db reset in the Meridian CLI.

REQUIRES confirm: true in the SAME call. Omitting it, or passing false, refuses with a clear error and makes NO changes. Never call this tool speculatively or "just in case". Only pass confirm: true when you (or the developer you are acting for) have explicitly decided to permanently discard this developer database's current contents.

Also refuses if the developer database is not currently ready (e.g. still provisioning, or already in an error state). Use dev_database_get to check status first if unsure. Takes the app_id returned by apps_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>",
      "confirm": "<confirm>"
    },
    "name": "dev_database_reset"
  }
}

Input Schema

Name	Required	Description
`app_id`	Yes	The app uuid returned by `apps_list`.
`confirm`	Yes	Must be exactly `true`. Resetting permanently destroys the developer database's current contents; this tool refuses without explicit confirmation.
`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.5/5.0

Behavior5/5

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

Annotations only flag destructiveHint=true; the description goes much further by naming exactly what is destroyed (tables and rows), what is preserved (MySQL user/credentials), the `confirm: true` gate and its refusal behavior with no changes made, and the `ready`-state precondition with a defined refusal path. This is behavior an agent cannot infer from the annotation set.

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 irreversibility warning, then confirmation mechanics, then preconditions and ID sourcing — a sensible risk-ordered structure. There is mild redundancy ("Only the data is wiped" restates the preceding clause, and the confirm requirement appears again in the schema), but the repetition is defensible for a destructive tool.

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?

Covers preconditions, refusal modes, ID sourcing and the CLI equivalent, which is ample for a three-parameter destructive tool with no output schema. The one unstated detail is post-reset state — whether the database returns as `ready` or re-provisions — which would help an agent plan the next call.

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 all three parameters are already documented, including `confirm` requiring exactly true and `organization_id` changing how `app_id` resolves. The description adds the useful constraint that `confirm: true` must be in the SAME call, but otherwise restates schema content, so the baseline 3 applies.

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 ("drops and recreates the CALLING user's own developer database schema") plus the exact blast radius: every table and row destroyed, replaced with an empty schema, while the MySQL user/credentials survive. An agent can distinguish this from siblings like dev_database_migrate or dev_database_get purely from the text.

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?

Explicit when-to-use (only after an explicit decision to permanently discard the contents) and when-not ("Never call this tool speculatively or 'just in case'"). It also routes the agent to the right siblings: dev_database_get to check `status` first and apps_list as the source of `app_id`.

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?