Delete a service from a Tugport panel when you need to remove it; set volumes=true to also erase its stored data. Requires the destroy grant.
Delete a service (needs the destroy grant). volumes=true also deletes its data.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Service id or `project.service`, e.g. `shop.api` | |
| volumes | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden; it does name a permission requirement and warns that volumes=true destroys data. However, it never says the service deletion itself is irreversible, nor what happens to dependents such as deploys, domains, or env vars.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the destructive capability surfaced before any secondary detail. Every clause adds information an agent would otherwise have to guess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, two-param tool with no annotations and no output schema, the essentials (permission, data deletion) are covered, but side effects on related resources and confirmation of permanence are absent. That is a meaningful gap for an irrecoverable operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: the `volumes` param has no schema description, and the description compensates by explaining that volumes=true deletes the service's data — the key semantic an agent needs. The `service` identifier format is handled in the schema, so nothing is left ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Delete a service') with the destructive scope stated up front. It is plainly distinguishable from the lifecycle siblings (stop, restart, update_service) because it removes the resource rather than altering its state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The prerequisite '(needs the destroy grant)' is a useful call condition, but the description never contrasts this with stop or restart, which are the obvious alternatives an agent will be choosing between. The agent must infer that delete is the terminal option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This server cannot be deployed