mcp-cloudflare-crunchtools

Purge Cache Tool

purge_cache_tool

Purge cached content from Cloudflare's edge by files, tags, hosts, or prefixes, or purge everything to clear a zone.

Instructions

Purge cached content from Cloudflare's edge.

Use one of: purge_everything, files, tags, hosts, or prefixes. Every method works on every plan, Free included. Prefer hosts, prefixes, tags or files over purge_everything when only part of a zone is stale.

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": {
      "zone_id": "<zone_id>"
    },
    "name": "purge_cache_tool"
  }
}

Input Schema

Name	Required	Description
`tags`	No	Cache tags to purge
`files`	No	URLs to purge (max 30)
`hosts`	No	Hostnames to purge
`zone_id`	Yes	Zone ID (32-character hex string)
`prefixes`	No	URL prefixes to purge
`purge_everything`	No	Purge all cached content

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.7.2Oct 12, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / files / description
```
Added value: +"URLs to purge (max 30)"
```
- addedInput schema / properties / hosts / description
```
Added value: +"Hostnames to purge"
```
- addedInput schema / properties / prefixes / description
```
Added value: +"URL prefixes to purge"
```
- addedInput schema / properties / purge_everything / description
```
Added value: +"Purge all cached content"
```
- addedInput schema / properties / tags / description
```
Added value: +"Cache tags to purge"
```
- addedInput schema / properties / zone_id / description
```
Added value: +"Zone ID (32-character hex string)"
```
Changed7 schema fields changedv0.5.1Oct 1, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / files / description
```
Removed value: -"URLs to purge (max 30)"
```
- removedInput schema / properties / hosts / description
```
Removed value: -"Hostnames to purge (Enterprise)"
```
- removedInput schema / properties / prefixes / description
```
Removed value: -"URL prefixes to purge (Enterprise)"
```
- removedInput schema / properties / purge_everything / description
```
Removed value: -"Purge all cached content"
```
- removedInput schema / properties / tags / description
```
Removed value: -"Cache tags to purge (Enterprise)"
```
- removedInput schema / properties / zone_id / description
```
Removed value: -"Zone ID (32-character hex string)"
```
First observedv0.5.0Aug 19, 2026

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that every method works on all plans including Free and implicitly frames purge_everything as the blunt instrument, but it never states that purging is irreversible, that it degrades origin load, or any rate-limit/permission behavior an agent should expect.

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 short sentences, front-loaded with the core action before the method list and the preference rule. The 'Every method works on every plan' sentence is slightly tangential but does carry real information, so no sentence is pure waste.

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?

An output schema exists, so return values need not be described. With 100% schema coverage and a complete method-choice rule, the only gap is the destructive/irreversibility caveat, which is a notch below complete yet still leaves the agent able to call the tool correctly.

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%, so each parameter (tags, files, hosts, prefixes, purge_everything, zone_id) is already documented in the schema. The description reinforces the mutual-exclusivity ('use one of') relationship between the method parameters, which is mild added value, but adds no format or limit detail beyond the schema.

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 (purge) and resource (cached content) with scope (Cloudflare's edge). No sibling tool touches cache, so the purpose is unambiguous against the surrounding zone/DNS/WAF/analytics tools.

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?

Explicitly enumerates the five selectable methods and gives a selection rule: prefer hosts, prefixes, tags or files over purge_everything when only part of a zone is stale. This is real when-to-use guidance, not a restatement of the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server