Skip to main content
Glama

Honeyfield Marketing MCP

Business Profile: Delete media

gbp_delete_media
Destructive

Löscht ein hochgeladenes Foto/Medium. media_id: die ID aus gbp_list_media (nur Buchstaben, Ziffern, _ und -) — sonst {"error":"invalid_media_id"}. workspace: Slug des Kunden-Workspace (optional bei nur einem Workspace).

Input Schema

NameRequiredDescriptionDefault
media_idYes
workspaceNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/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 known. The description adds real value beyond that by documenting the accepted media_id charset and the exact failure response ({"error":"invalid_media_id"}), but it does not state that the deletion is permanent/irreversible or what happens on a missing ID, which is the main behavioral question for a destructive op.

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 dense sentences with the action front-loaded and the parameter notes following; no filler. The inline JSON error string is slightly noisy but is informative rather than redundant.

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

Completeness4/5

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

With an output schema present, return values need not be explained, and both parameters are covered. The only meaningful gap for a destructive tool is an explicit permanence/no-undo statement, which the description leaves to the annotation alone.

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 coverage is 0%, so the description carries the full burden and largely does: media_id gets its source (gbp_list_media), an allowed-character constraint and an error outcome; workspace gets a meaning (customer workspace slug) and an optionality rule (only needed when more than one workspace exists). Only the exact slug format/where to obtain it is left implicit.

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 and object ('Löscht ein hochgeladenes Foto/Medium'), which unambiguously identifies a deletion of an uploaded media asset and implicitly separates it from gbp_upload_media/gbp_list_media. It does not explicitly name the sibling alternatives, but the resource scope leaves little ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description points the agent to gbp_list_media as the source of media_id, which is a genuine prerequisite hint. However, it never states when deletion is appropriate versus alternatives, nor any exclusion (e.g. that the media is permanently removed and cannot be restored, or whether posts referencing the media are affected).

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