Skip to main content
Glama

Kling AI MCP Server by useapi.net (third-party)

Delete a Kling 4.0 voice

kling_delete_voice
DestructiveIdempotent

Delete one of your saved Kling 4.0 voices by id (from kling_list_voices or kling_save_voice). Cannot be undone. DELETE /videos/voices.

Input Schema

NameRequiredDescriptionDefault
emailNoThe Kling account email. Required when the token has several Kling accounts.
voiceIdYesThe voice id (digits).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is largely covered. The description adds the critical operational fact 'Cannot be undone', which is genuinely useful irreversibility context beyond the annotation flags.

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?

Two sentences plus an endpoint reference, with the action front-loaded and zero filler. Every clause (id source, irreversibility, route) carries information an agent needs.

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 simple single-resource delete with full schema coverage and annotations covering the safety profile, nothing further is needed; no output schema is required and return values are irrelevant. The definition is complete as written.

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 description coverage is 100%, so both parameters are documented (email conditional, voiceId as digits) and the baseline would be 3. The description adds provenance for voiceId (obtained from kling_list_voices or kling_save_voice), which is meaning the schema does not supply.

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+resource ('Delete ... Kling 4.0 voices by id') and scopes it to the user's saved voices, which cleanly separates it from the many sibling delete tools (kling_delete_avatar, kling_delete_element, kling_delete_task). It even names the endpoint, leaving no ambiguity about what is being removed.

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?

It tells the agent where the required id comes from (kling_list_voices or kling_save_voice) and warns the action is irreversible, which is the key precondition for calling it. It does not, however, state any when-not-to-use condition or contrast with the other delete siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources