Skip to main content
Glama
nerdit-ai

Nerdit

Official
by nerdit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

remove_service

Deletes an existing app, model, or database service by tearing down its resources and removing its record. Optionally bypass dependency guards or purge durable state like secrets and data.

Instructions

Delete a service (teardown + remove).

Input Schema

NameRequiredDescriptionDefault
nameYesService name or job id of an existing service (app, model or database); both resolve to the same row.
forceNotrue bypasses the dependency guard (a model or database other apps still bind), kills an in-flight run and cancels an in-flight cutover; a cross-owner dependent makes it admin-only. false (the default) refuses those with 409 ``resource.in_use`` / ``service.run_in_progress`` / ``service.cutover_in_progress``.
purgeNoCSV of durable state to destroy alongside the row: ``secrets``, ``data``, ``images``, ``workspace``. Default ``secrets``; an empty string purges nothing; an unknown token is a 422 ``service.invalid_purge``. Deleting a managed DATABASE requires ``data`` in the set (409 ``db.delete_requires_purge``, not bypassable by ``force``), and purging ``data`` always purges ``secrets`` too.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

B3.1/5.0
Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden, yet it only says 'teardown + remove'. It omits irreversibility, dependency guards, 409 behaviors, admin-only cases, and purge semantics — all of which live in the schema, not the description. 'Teardown' hints at state destruction but is too vague for a destructive tool with zero annotation coverage.

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

Conciseness5/5

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

A single short sentence, front-loaded with the verb and resource, with zero filler. It is exactly as long as the description needs to be, given the schema handles the details.

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

Completeness3/5

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

Given a destructive operation with no annotations and no output schema, the description is minimally complete: it tells the agent the operation removes a service, but not enough about risk, prerequisites, or the stop-vs-delete decision. The rich schema compensates for parameter-level gaps but not for top-level behavioral framing.

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%, and the parameter docs are unusually rich (force dependency bypass, purge token semantics, idempotency replay). The description adds nothing beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Delete a service') and adds a scoping note ('teardown + remove') indicating it does more than stop it. However, it does not distinguish itself from sibling stop_service, which is the closest alternative an agent would consider.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusion criteria, and no mention of stop_service as an alternative for reversible shutdowns. The agent must infer that permanent removal versus stopping are different paths.

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