Skip to main content
Glama

hcloud_load_balancer_delete_service_action

Destructive

Deletes a load balancer service by listen port and optionally polls the resulting action until success or error.

Instructions

Delete Service

Delete a service of a Load Balancer.

Input Schema

NameRequiredDescriptionDefault
idYesID of the Load Balancer.
bodyYes
waitNoPoll the resulting action until success/error or timeout.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. Beyond that, the description adds nothing: it does not say the deletion is irreversible, what happens to in-flight traffic, what errors occur if the port does not exist, or how the 'wait' parameter governs the returned action.

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

Conciseness3/5

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

Two short lines, front-loaded and free of padding, but the first line merely restates the tool name as a title and the second is a near-verbatim restatement. It is concise without being informative.

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

Completeness2/5

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

This is a destructive mutation with a required nested body and an async action/'wait' pattern, and there is no output schema. The description explains none of that lifecycle: whether an action ID is returned, what happens on timeout, or what the caller should do next. For a tool of this complexity it is materially incomplete.

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

Parameters2/5

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

Schema description coverage is 67%, with the 'wait' parameter documented only in the schema and the nested 'body.listen_port' described there too. The description adds no parameter meaning at all, so it does not compensate for the remaining coverage gap nor explain the required nested body shape.

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?

The description states a specific verb (Delete) and resource (a service of a Load Balancer), which distinguishes it from siblings such as hcloud_load_balancer_add_service_action and hcloud_load_balancer_update_service_action by implication. However, it never names those siblings or clarifies that 'service' means a listener/service entry on the LB.

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 statement of when to use this tool versus add_service or update_service, no prerequisites, and no warning about consequences. The agent must infer everything from the tool name and the broader sibling list.

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