Inspect Local SQLite Cache Health

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

The annotations already include readOnlyHint: true, idempotentHint: true, and destructiveHint: false, which establish the tool as a safe read-only operation. The description adds valuable context beyond annotations by specifying the offline nature ('without Telegram API calls') and the specific diagnostics it returns (integrity, size, tier). This extra context helps the agent understand the operational scope and side-effect-free behavior.

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 concise, two sentences, and front-loads the key purpose and the use case. Every word adds value: the first sentence lists specific diagnostics, the second gives the usage trigger and a key behavioral trait (offline). No wasted words or redundancy.

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 tool with zero parameters and a rich output schema (which likely details the return values), the description is complete. It covers the purpose, usage context, and key behavioral trait (offline). The annotations cover safety, and the output schema handles the return format. Nothing important is missing for an agent to decide whether and how to invoke it.

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, and the schema coverage is 100% (trivially, as there are no parameters). The description doesn't need to document parameters. Since there are none, the baseline is 3, and the description adds no parameter-specific information because there is nothing to add. This is appropriate.

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 clearly states that the tool inspects local SQLite/FTS5 archive integrity, database size, and active tool tier diagnostics. It distinguishes itself from sibling tools by focusing on cache health rather than chat operations or search. The purpose is specific and actionable, though it doesn't explicitly name a sibling alternative.

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 explicitly states when to use this tool: 'Use to verify cache readiness before running local searches.' This provides clear guidance on the trigger condition, and the mention of 'Operates entirely offline without Telegram API calls' implies it is a safe, low-cost operation compared to API calls. However, it doesn't explicitly say when not to use it or name alternatives, which is a minor gap.

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