sync_lolfarm

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states the effect (pulling fresh data into cache), partial-failure behavior ('Failures in one source never block the others'), and the return shape ('per-source counts + errors'). This is meaningful context beyond a simple one-line summary.

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?

The description is three tight sentences, each carrying distinct value: what it does, when to run it, and how it handles failures/returns. It is front-loaded with the core purpose and contains no filler or redundant restatement.

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?

For a single-optional-parameter sync tool, the description is complete: it specifies the data sources, the scheduling context, the failure-isolation behavior, and the return summary. There is no output schema, but the description covers the essential return information ('per-source counts + errors') without needing further detail.

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?

The input schema already documents the optional 'source' parameter with a full enum and an explanatory description including the 'omit to sync all 8 in parallel' behavior. The tool description adds no additional parameter-level detail, so it stays at the baseline 3 for high schema coverage.

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?

The description uses a specific action verb ('Pull fresh data') with a clear resource ('LOLFarm upstream sources') and destination ('local cache'). It enumerates the exact upstream source families, making it easy to distinguish from the many lookup/search sibling tools such as lookup_lolbas or search_lolfarm.

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 description gives explicit scheduling context ('Run weekly via scheduled task') and a rationale tied to upstream update frequency (1-4x per month). It does not explicitly name alternative tools or state when not to use it, but the cadence and cache-focused wording imply it is a maintenance operation rather than an ad-hoc lookup.

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