Force-refresh all CellarTracker data by downloading fresh CSV exports for all eight tables regardless of cache age.
Force refresh all CellarTracker data from the server. Downloads fresh CSV exports for all 8 tables regardless of cache age.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| tables | Yes | ||
| refreshedAt | Yes | ||
| serverVersion | Yes |
Changes observed during successful MCP inspections.
v0.5.1Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, but the description says it 'Downloads fresh CSV exports' and 'Force refresh' — a write-like side effect (cache mutation, network I/O). This is not a direct contradiction (the server data isn't modified), but the description does not reconcile the readOnlyHint with the cache-updating behavior. It also doesn't mention network cost, duration, or failure modes for downloading 8 tables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action and scope. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values needn't be explained. However, for a tool that triggers a full server download, the description should address the readOnlyHint vs. cache-write tension and note any cost/latency implications. The core purpose is clear but the behavioral context is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The schema is 100% covered (empty), and the description correctly handles the absence of parameters by describing the fixed scope (all 8 tables, all cache ages).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Force refresh') and resource ('all CellarTracker data from the server'), and clarifies the scope with 'all 8 tables'. An agent can immediately distinguish this from read-only siblings like get-wishlist or cellar-stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'regardless of cache age' implies usage for cache invalidation, but the description never explicitly says when to use this tool versus simply querying the cached data. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.