Skip to main content
Glama

media_delete

Destructive

Deletes a file from the media library permanently, to clean up after yourself: an upload that turned out wrong, or a file the user no longer wants stored (it frees the storage it counted against). The file must be unused - one any Riddle still shows is refused with a message naming those Riddles, since deleting it would leave a broken image behind in a live Riddle; remove it there first (riddle_builder_update, then riddle_publish so the change is live) and delete afterwards. Unused is a property of the file across the whole ACCOUNT, not of one Riddle: several Riddles can use it and any one of them keeps it alive, and a file the Creator lists as in use cannot be forced out from here either. Not reversible, no undo, and the id is not reused, so anything still pointing at the file stops resolving - ask the user before calling this. Returns {deleted: true, mediaId, name, type, size}. Without full access only files in the "AI Uploads" folder (media_upload_link's destination): riddle://reference/concepts/access.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mediaId": "<mediaId>"
    },
    "name": "media_delete"
  }
}

Input Schema

NameRequiredDescriptionDefault
mediaIdYesThe media library id of the file to delete - the "mediaId" the upload response returned, or the id shown for the file in the Creator's media library.
projectNoProject ID; NULL or omitted: your personal project (project API key: its project). A mediaId only resolves in its project - build in the same one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
      +  "default": null,
      +  "description": "Project ID; NULL or omitted: your personal project (project API key: its project). A mediaId only resolves in its project - build in the same one.",
      +  "type": [
      +    "null",
      +    "integer"
      +  ]
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the destructive/not-idempotent annotations, the description adds substantial context: no undo, ids are not reused, dangling references stop resolving, refusals name the Riddles that block deletion, 'unused' is account-wide rather than per-Riddle, and a permission restriction limiting non-full-access callers to the AI Uploads folder.

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?

Dense but front-loaded: the action and permanence come first, then prerequisites, then the alternative workflow, then the return shape. It is a long single paragraph, but nearly every clause carries decision-relevant information.

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 destructive tool with no output schema, the description supplies the return shape ({deleted, mediaId, name, type, size}), the failure mode when the file is still in use, and the permission caveat. An agent has everything needed to call it safely or route elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and already documents both mediaId and project, including that a mediaId only resolves in its project. The description adds little parameter-specific detail beyond the account-wide framing, so it sits at the baseline.

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 and resource ('Deletes a file from the media library permanently') and scopes it as cleanup of an unwanted or erroneous upload. It is clearly distinguishable from media_upload_link and from riddle_delete, which act on different resources.

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

Usage Guidelines5/5

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

Gives explicit when-to-use cases (wrong upload, file no longer wanted), the prerequisite (file must be unused), and the exact alternative workflow when the file is in use: remove it via riddle_builder_update, then riddle_publish, then delete. It also warns to ask the user before calling.

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