Skip to main content
Glama
crunchtools

io.github.crunchtools/airlock

Official
by crunchtools

Cache Flush Tool

cache_flush_tool

Clears cached tool lists for your profile, forcing a rebuild on the next request. Operators can flush a specific backend or all scoped caches.

Instructions

Flush gateway tool list caches.

Scoped to the calling profile: it drops your own tool-list aggregate so the next tools/list rebuilds it. Backend tool lists are shared between profiles and only an operator profile flushes them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
backendNoA backend in your profile (e.g. "rt", "wiki"); it must exist there, and the result is the same either way. An operator flushes that backend everywhere it is configured. Omit for everything in scope.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.49.0
    • changedInput schema / properties / backend / description
      Previous value: -"Backend name to flush (e.g. \"rt\", \"wiki\"). Omit to flush\neverything in scope."New value: +"A backend in your profile (e.g. \"rt\", \"wiki\"); it must exist\nthere, and the result is the same either way. An operator flushes\nthat backend everywhere it is configured. Omit for everything in\nscope."
  2. Changed1 schema field changedv0.12.0
    • changedInput schema / properties / backend / description
      Previous value: -"Backend name to flush (e.g. \"rt\", \"wiki\"). Omit to flush all."New value: +"Backend name to flush (e.g. \"rt\", \"wiki\"). Omit to flush\neverything in scope."
  3. First observedv0.5.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful behaviour: the flush is scoped to the calling profile, comes back after the next tools/list, and shared backend lists require an operator profile. It does not state permission requirements, whether the operation is synchronous, or any rate limits, so a full 5 is not warranted.

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?

Three short sentences: purpose first, then the caller-scoping rule, then the shared-backend caveat. Every sentence carries distinct, load-bearing information and nothing is repeated from the schema or title.

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

Completeness4/5

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

The tool is simple (zero required params, output schema present so return values need no prose), and the description covers the non-obvious scoping semantics fully. The remaining gap is the permission model — it alludes to an 'operator profile' without saying how the caller's identity is established.

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 the sole 'backend' parameter is already fully documented in the schema (including the 'same either way' note and the omit-for-everything default). The description adds no parameter-level detail beyond that, which is the defined baseline for complete schema coverage.

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 and resource ('Flush gateway tool list caches') and immediately qualifies the scope, so the agent knows exactly what aggregate is dropped. It does not name any sibling (e.g. reload_profiles_tool) to route against, which is the only thing keeping it from a 5.

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?

Explains the operative context: it drops your own tool-list aggregate 'so the next tools/list rebuilds it', which tells the agent when this is the right call. It offers no explicit exclusions or named alternatives among the siblings, so it stops short of a 5.

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