spawnpoint

Remove database

remove_database

DestructiveIdempotent

Remove a project's managed Postgres database and unset DATABASE_URL: the app loses the database and all its data now. spawnpoint keeps it for 7 days, and a person who may delete the project (its owner; on a team, its builder or a team admin) can restore it from the project's Storage panel in the console; after that it is deleted for good. Even when the user asked for it, first reply telling them the app loses the data, ask them to confirm, and stop; call with confirm: true only after they answer yes. Without confirm the call refuses and nothing happens. The app restarts without the variable. To replace a leaked DATABASE_URL instead, use rotate_database_password. A protected project refuses it: only its owner turns protection off, on the project's page in the console, so relay the refusal instead of looking for another way.

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": {
      "project_id": "<project_id>"
    },
    "name": "remove_database"
  }
}

Input Schema

Name	Required	Description	Default
`confirm`	No	true only once the user, told what the tool's description says is lost, answered yes to that question. The request to remove it is not that yes: ask first, and stop
`project_id`	Yes	the id of the project

Output Schema

Name	Required	Description	Default
`env`	No
`note`	Yes
`status`	Yes
`database`	No
`project_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / confirm / description

Previous value: -"true only once the user, told that the data is deleted for good, answered yes to that question. The request to remove it is not that yes: ask first, and stop"New value: +"true only once the user, told what the tool's description says is lost, answered yes to that question. The request to remove it is not that yes: ask first, and stop"

First observedOct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the destructiveHint/idempotentHint annotations by disclosing that data loss is immediate, that spawnpoint retains the database for 7 days, who can restore it (owner, or team builder/admin) and where, and that the app restarts without the variable. The refusal behavior for protected projects and the no-op without confirm are also spelled out.

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-loads the action and consequence, then layers confirmation, restoration, and refusal. It runs long and mildly redundantly restates the confirm protocol already in the schema ("Without confirm the call refuses and nothing happens"), but no sentence is filler given the destructive nature.

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?

For a destructive two-parameter mutation with an output schema, everything an agent needs is present: loss scope, recovery window, authorization, confirmation flow, and rollback avoidance. Return values are correctly left to the output schema.

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

Parameters4/5

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

Schema coverage is 100% and project_id is trivial, so the schema carries most of the load. The description still adds workflow meaning to confirm — that it must follow an explicit user yes and that a removal request is not itself a confirmation — and states that the call refuses without it.

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 ("Remove a project's managed Postgres database and unset DATABASE_URL") plus the immediate consequence. It also names the sibling it is not (rotate_database_password), so the agent can distinguish it without opening another schema.

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 routing: use this to drop the database, use rotate_database_password to replace a leaked URL. It gives the prerequisite confirmation protocol (ask, stop, call only after a yes), states the outcome of omitting confirm, and explains what to do when a protected project refuses rather than hunting for a workaround.

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

All spawnpoint 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.