Skip to main content
Glama
nerdit-ai

Nerdit

Official
by nerdit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

delete_project

Delete a project and all its services to release the project name. The project row is removed only after every service is deleted; refusals leave it intact.

Instructions

Delete a project: every service in it, then the row, releasing the name.

    Services go one by one through the same cascade as ``remove_service``
    (owner-or-admin each; a dependency guard or an in-flight run refuses a
    service exactly as there). The project row goes last and only when
    every service went: a refusal leaves the project in place with 409
    ``project.delete_incomplete`` listing ``deleted`` and ``failed``, and
    re-running after the fix is idempotent. Owner or admin only.

Input Schema

NameRequiredDescriptionDefault
nameYesImmutable prj_ ID or name of an existing project. Prefer the ID from list_projects: a retired ID never addresses a same-name replacement.
purgeNoCSV of durable state to destroy alongside EVERY service in the project: ``secrets``, ``data``, ``images``, ``workspace``. Default ``secrets``; an empty string purges nothing; an unknown token is a 422 ``service.invalid_purge``.secrets
idempotency_keyNoCaller-chosen key: a retry with the same key replays the first result instead of acting twice. Omit and a fresh key is minted per call, so each call acts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it discloses destructive cascade order, that the row is deleted only if all services succeed, the 409 project.delete_incomplete response with deleted/failed lists, idempotent re-run behavior, and the owner-or-admin authorization requirement.

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 core action ('Delete a project:...') and every following sentence adds concrete behavior (cascade, refusal shape, idempotency, auth). It is dense and slightly long-winded with parentheticals, but no sentence is filler.

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 destructive mutation with no annotations and no output schema, the description covers order of operations, failure response, idempotency, and permissions well. The one meaningful gap is that it does not restate that purge destroys durable state (secrets/data/images/workspace), leaving that critical destructive detail entirely to 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 coverage is 100%, so name, purge, and idempotency_key are already fully documented in the schema, establishing the baseline of 3. The description's mention of 'releasing the name' mildly reinforces the name parameter but adds no syntax, defaults, or purge semantics beyond what the schema provides.

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 ('Delete a project') and enumerates exactly what is removed and in what order, including that the name is released. It is distinguishable from sibling remove_service by explicitly noting the project row and the cascade through all contained services.

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?

By saying services go through 'the same cascade as remove_service,' it implicitly tells the agent that single-service removal belongs to remove_service and full-project teardown belongs here. It does not fully spell out when-not/exclusions, so it stops short of a 5, but the routing signal is clear.

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