Skip to main content
Glama
Sign In
ohneben's Wafeq MCP

ohneben's Wafeq MCP

by ohneben
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

wafeq_files_destroy

DestructiveIdempotent

Permanently delete an existing file in Wafeq using its ID. Irreversible action that removes the file record from the system.

Instructions

🔴 DESTRUCTIVE · deletes · Files · DELETE /files/{id}/

Delete file

Endpoint for deleting an existing file.

Permanently removes the record.

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": {
      "id": "<id>"
    },
    "name": "wafeq_files_destroy"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
idempotency_keyNoOptional idempotency key (sent as the X-Wafeq-Idempotency-Key header). A UUID v4 is generated automatically when omitted, so an automatic network retry can never duplicate this operation. Pass your own stable value to make a deliberate re-invocation safe as well.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.2/5.0
Behavior4/5

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

The description adds 'Permanently removes the record', which goes beyond the destructiveHint=true annotation by disclosing irreversibility — valuable for an agent deciding whether deletion is safe. The 🔴 DESTRUCTIVE marker and delete wording are consistent with readOnlyHint=false, idempotentHint=true, and destructiveHint=true; no contradiction.

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

Conciseness2/5

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

Four statements where three restate the same fact — 'deletes · Files', 'Delete file', and 'Endpoint for deleting an existing file' — and the emoji/uppercase warning duplicates the destructiveHint annotation. The genuinely informative content (endpoint path, permanence) is front-loaded, but the repetition wastes tokens and should be collapsed to one or two lines.

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

Completeness3/5

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

For a low-complexity tool (2 params, no output schema, rich annotations) the core is covered: what it deletes, that it is permanent, and idempotency behavior in the schema. Gaps remain: no mention of where the id comes from (files_list/upload siblings), no consequences of deleting a referenced file, and no error/response behavior given the absence of an output schema.

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 coverage is exactly 50%; the idempotency_key parameter is thoroughly documented in-schema (header name, UUID v4 auto-generation, retry safety), while the required id parameter has no schema description. The tool description does not explain id, though 'DELETE /files/{id}/' in the opening line offers a minimal hint that id is the file path identifier. Neutral baseline with partial compensation from the schema.

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+resource: 'deletes · Files', 'Delete file', 'Endpoint for deleting an existing file', and gives the HTTP method/path 'DELETE /files/{id}/', which makes the target concrete and distinguishes it from files_list, files_retrieve, and upload_file siblings. Not a 5 because the same idea is repeated three-plus times and 'Permanently removes the record' slightly blurs whether the file blob or just the database record is removed.

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?

No guidance on when to choose this over alternatives, no prerequisites (e.g., obtaining the id from wafeq_files_list or a prior upload), and no exclusions such as files still referenced by invoices. The only usage signal is the implied 'use this to delete a file' carried by the purpose statement itself.

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