Skip to main content
Glama

catalog_delete_scenario_branding

DestructiveIdempotent

Deletes a notification scenario branding in VCF Automation to remove outdated branding from notification scenarios.

Instructions

Deletes a notification scenario branding DELETE /notification/api/scenario-branding

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.2/5.0
Behavior3/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 covered. The description adds only the underlying HTTP route (DELETE /notification/api/scenario-branding); it does not say what is actually removed, whether the deletion is recoverable, or what permissions are needed. Critically, with zero parameters it never explains how the target branding is selected (session/tenant scope), which is the key behavioral unknown here.

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

Conciseness4/5

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

Two short lines with the action front-loaded, no filler. The raw HTTP route is of marginal value to an agent but does not bloat the definition.

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?

For a destructive, parameterless deletion the description should at minimum explain what object is targeted and how scope is determined, plus any irreversibility warning. With no output schema and no such detail, an agent cannot confidently predict the effect of calling it.

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?

The schema declares zero parameters and 100% description coverage, so there is nothing parameter-level for the description to compensate for. The only deduction is that it never clarifies the implicit scoping that makes a parameterless delete meaningful.

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?

States a specific verb ('Deletes') and resource ('notification scenario branding'), so the operation is identifiable. It does not differentiate from near-name siblings such as catalog_delete_scenario_configs_by_scenario_id or catalog_delete_icons_by_id, which an agent must disambiguate on its own.

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 when-to-use guidance, no prerequisites, and no mention of the related catalog_get_scenario or catalog_preview_notification_config siblings that would let an agent confirm the target first. The agent is left to infer everything from the name.

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