datalens_trinoclusters_deleteDelete a Trino cluster by ID and return the deletion operation. Use this MCP tool to remove an existing cluster and track its removal status.
Delete a Trino cluster and return the operation that deletes it.
Experimental in the DataLens API, written from its document and never called: not measured.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id of the Trino cluster. |
Changes observed during successful MCP inspections.
v0.122.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds that the call returns an asynchronous operation object (important since there is no output schema) and that the endpoint is experimental and never actually measured, but it never states what is destroyed beyond the cluster itself (e.g., whether catalogs/data are cascaded).
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 short sentences, with the core action and return value front-loaded. The second sentence is a meta caveat about the API rather than tool behavior, but it is brief and does not bloat the definition.
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 one-parameter destructive delete with full annotation coverage and no output schema, the description covers the action and the async return, which is most of what an agent needs. It omits any note on irreversibility, cascade effects, or permissions, which would matter for a destructive cluster removal.
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?
There is a single required 'id' parameter with 100% schema description coverage, so the schema fully documents it. The description adds nothing about the id (format, source, or whether a cluster name works instead), so the baseline of 3 applies.
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?
The description gives a specific verb and resource ('Delete a Trino cluster') and states the return ('the operation that deletes it'), so the agent knows exactly what it does. It does not explicitly distinguish itself from the close sibling datalens_trinoclusters_catalog_delete, which also deletes a Trino-related resource, so it stops short of a 5.
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 description offers no when-to-use guidance, no prerequisites, and no alternative tools or conditions for choosing deletion over stopping (datalens_trinoclusters_stop) or deleting a catalog. Usage must be inferred entirely from the name and annotations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.