Skip to main content
Glama
anythink-cloud

Anythink-MCP

Official

Files: delete

files_delete
Destructive

Delete a stored file by ID, removing it from project storage and cascading to records that reference it by default. Check with files_get first if unsure.

Instructions

Delete a file by ID. Removes the file from the project's storage by its id. Records that reference it through a file field follow that field's on-delete rule; with the default, CASCADE, they are deleted too. To see what is stored first, use files_get. It changes or deletes existing data, so check with the user before running it.

Input Schema

NameRequiredDescriptionDefault
idYesFile ID to delete. Find it with files_list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.37
    • changedInput schema / properties / id / description
      Previous value: -"File ID to delete"New value: +"File ID to delete. Find it with files_list."
  2. Addedv0.2.27

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds the decisive behavior the annotations cannot convey: references via a file field follow that field's on-delete rule and default to CASCADE, so related records are deleted too. It also advises user confirmation before running, which is meaningful risk context for a destructive operation.

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?

Four tight sentences that lead with the core action, then consequence, then alternative, then caution — good front-loading. The second sentence ('Removes the file from the project's storage by its id') largely restates the first, a minor redundancy.

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 single-parameter destructive tool with no output schema and destructiveHint already set, the description covers the action, the cascade side effect, the discovery path (files_get/files_list), and the confirmation expectation. Nothing an agent needs to call this safely is missing.

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 the single `id` parameter is already documented there, including how to find it via files_list. The description only restates 'by ID' and adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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 ('Delete a file by ID') and immediately scopes it with the cascade consequence, distinguishing it from siblings like files_get and files_list. An agent knows exactly what this tool does without opening the schema.

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

Usage Guidelines4/5

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

Names the alternative for inspection ('To see what is stored first, use `files_get`') and gives a pre-execution guardrail ('check with the user before running it'). It does not spell out when deletion is inappropriate or name non-file deletion tools, so it stops just short of full when/when-not coverage.

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