Skip to main content
Glama
KnockOutEZ

wigolo

by KnockOutEZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

cache

Destructive

Search previously fetched content locally before hitting the network to avoid redundant fetches; returns matching markdown, stats, and change checks from persisted entries.

Instructions

Search previously fetched content without hitting the network. Run this BEFORE any search/fetch — cache hits return instantly with full markdown.

Key parameters:

  • query: FTS5 full-text search over cached markdown + titles (supports AND, OR, NOT, "phrase").

  • url_pattern: glob filter on URLs (e.g. "example.com").

  • since: ISO date — only entries cached after this date.

  • stats: true to get cache size, entry count, oldest/newest dates.

  • clear: true to delete matching entries.

Persists across sessions. No remote round-trip.

Input Schema

NameRequiredDescriptionDefault
modeNoSearch strategy when query is provided. "fts" (default) runs keyword-only BM25 over the FTS5 index. "hybrid" additionally runs semantic vector search and fuses both rankings with reciprocal rank fusion for higher-recall lookups; falls back to FTS when the embedding index is empty or unavailable.
clearNoClear matching cache entries (requires at least one filter: query, url_pattern, or since)
limitNoMaximum number of results to return (default 20).
queryNoFull-text search over cached content
sinceNoISO date — only results cached after this date
statsNoReturn cache statistics (total URLs, size, date range)
url_patternNoFilter by URL glob pattern (e.g., "*example.com*")
check_changesNoRe-fetch all matching cached URLs and report which ones have changed. Returns a list of URLs with changed/unchanged status and diff summaries. Use with query or url_pattern to scope which cached entries to check.
max_tokens_outNoToken-budget cap on total output (cl100k-base BPE). Caps the aggregate size of all returned markdown bodies; bodies past the budget are truncated or dropped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0
  2. Removedv0.2.0
  3. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so safety characteristics are conveyed. The description adds useful behavioral context — instant cache hits with full markdown, persistence across sessions, and no remote round-trip — but doesn't elaborate on what exactly gets deleted by clear or the irreversibility of that action. It's still helpful beyond the annotations.

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 front-loaded with the core purpose, followed immediately by usage guidance, then a bulleted list of key parameters. Every sentence earns its place, and there is no wasted text.

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?

Given the complexity (9 parameters, no output schema, destructive clear operation), the description is complete enough for correct invocation. It explains the tool's role, when to prefer it, key parameter semantics, and persistence. Missing details about some parameters are fully covered by the schema descriptions.

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 coverage is 100%, so the schema already documents all parameters. The description adds operational meaning for key parameters: FTS5 syntax support (AND, OR, NOT, phrases) for query, a glob example for url_pattern, and the ISO date format for since. This goes beyond the schema's terse descriptions, though it doesn't mention mode, limit, check_changes, or max_tokens_out.

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 states a specific verb and resource: 'Search previously fetched content without hitting the network.' It immediately distinguishes itself from the sibling tools search and fetch by positioning itself as a local cache lookup rather than a live network operation.

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 gives explicit when-to-use guidance: 'Run this BEFORE any search/fetch — cache hits return instantly with full markdown.' This directly tells the agent when to choose this tool over its siblings, leaving little inference.

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