Skip to main content
Glama
CoderDayton

Semantic Cache MCP

by CoderDayton
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Delete

delete

Delete a single file or symlink and evict its cache entries, reporting not_found for missing paths. Use for explicit path removal without shell commands.

Instructions

Delete one file or symlink and evict its cache entries.

Use this for explicit single-path removal instead of shelling out. A missing path is reported as status not_found, not an error.

Statuses: deleted (removed), would_delete (dry-run preview only, and dry_run: true comes back with it), not_found (nothing was there). Constraints: one path only — no globs, no recursion, no real-directory deletes. A symlink path deletes the link itself, never its target.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesFile or symlink path (absolute, or relative to the project root).
dry_runNoPreview the outcome without deleting or evicting the cache.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "cache_removed": {
-      "anyOf": [
-        {
-          "type": "boolean"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "title": "Cache Removed"
-    },
-    "deleted": {
-      "anyOf": [
-        {
-          "type": "boolean"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "title": "Deleted"
-    },
-    "dry_run": {
-      "anyOf": [
-        {
-          "type": "boolean"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "title": "Dry Run"
-    },
-    "path": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "title": "Path"
-    },
-    "status": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "title": "Status"
-    },
-    "symlink": {
-      "anyOf": [
-        {
-          "type": "boolean"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "title": "Symlink"
-    },
-    "truncated": {
-      "anyOf": [
-        {
-          "type": "boolean"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "title": "Truncated"
-    }
-  },
-  "title": "DeleteResponse",
-  "type": "object"
-}New value: +null
  2. Changed2 schema fields changedv0.5.1
    • addedInput schema / properties / dry_run / description
      Added value: +"Preview the outcome without deleting or evicting the cache."
    • addedInput schema / properties / path / description
      Added value: +"File or symlink path (absolute, or relative to the project root)."
  3. Addedv0.4.5

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description fully carries the behavior disclosure burden. It explains status outcomes (`deleted`, `would_delete`, `not_found`), dry-run behavior, cache eviction, missing-path handling (not an error), and symlink-link vs. target behavior. This is exceptionally transparent 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.

Conciseness5/5

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

The description is well-structured and front-loaded: core action first, usage guidance second, statuses third, and constraints last. Every sentence carries useful information and none are redundant or filler. The density is justified given the tool's destructive nature and complex edge cases.

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?

Despite lacking annotations and an output schema, the description covers the essential operational context: what the tool deletes, how it handles edge cases (missing path, symlinks, directories, dry-run), and what statuses to expect. Nothing critical that an agent needs to call this tool correctly is missing.

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 description coverage is 100%, so the schema already documents both parameters. The description adds meaningful extra semantics beyond the schema, such as the `dry_run` status `would_delete` and path constraints (one path only, no globs, no recursion). This goes beyond the baseline but is primarily behavioral rather than deeply expanding parameter format details.

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?

The description opens with a specific verb and resource: 'Delete one file or symlink and evict its cache entries.' This clearly distinguishes it from sibling tools like read, write, edit, and clear, none of which perform single-path deletion. The scope is unambiguous.

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?

It explicitly states when to use the tool: 'Use this for explicit single-path removal instead of shelling out.' It also provides clear when-not constraints: one path only, no globs, no recursion, no real-directory deletes, and symlink-link-only semantics. These conditions enable an agent to select this tool correctly and avoid misuse.

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