GTM: Delete tag/trigger/variable

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 known. The description adds genuinely useful behavior beyond that: the deletion is staged and only takes effect after version + publish, and the preview returns the entity name, type and inbound references (e.g. tags on a trigger). It still doesn't say what happens when the entity is in use or whether the delete is recoverable after publish.

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 wasted words, with the irreversible nature and the two-step flow front-loaded. The preview/confirm contrast is stated as a single tight clause pair.

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 multi-parameter tool with no output schema, the definition covers the essential gaps: the staged publish requirement, what the preview returns, and when the real delete fires. It falls short only on edge behavior, such as dependency-blocked deletes or post-publish recovery, which an agent would want before invoking.

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 description coverage is 83%, and the confirm parameter is already documented in the schema as preview-only when omitted. The description reinforces the confirm semantics and adds what the preview contains, but adds no syntax, format or constraint detail for entityId, entityType or the account/container/workspace IDs. Baseline 3 is appropriate when the schema does the heavy lifting.

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 names a specific verb and resource ("Deletes an entity from the workspace") and scopes the effect ("live only after version + publish"). It distinguishes deletion from the write-oriented siblings like gtm_save_entity and gtm_revert_entity by verb alone, but never names those alternatives, and "entity" stays generic where the title says tag/trigger/variable.

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?

It gives explicit procedural guidance for the two modes: omit confirm for a safe preview, pass confirm=true to actually delete. That is a clear when/when-not rule for the tool's own parameter, though it offers no routing guidance against siblings such as gtm_revert_entity when the intent is to undo rather than remove.

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