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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds a genuinely non-obvious behavioral trait: the structured filters are post-filters over text results, so narrow filters plus a rare term can legitimately return few or zero results even when matches exist. That caveat materially changes how an agent should interpret an empty result set.

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 purpose and entry-point guidance are front-loaded, and every sentence carries information. The final sentence is a long run-on packing the post-filter caveat and the four alternatives together, which slightly hurts scannability.

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?

With an output schema present and annotations covering safety, the description needs only to add the caveats an agent cannot infer — and it does deliver the post-filter/empty-result warning. Limits behavior (pagination, default limit) and the semantics of the 'query' field itself are left to the schema.

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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does explain five of seven filters (resource_type, category, audience, skill, age) as post-filters over the text query — a semantic the schema does not convey. It stops short of describing valid value shapes or the limit default/max, so it is strong but not complete.

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+resource ('Free-text search across every public resource family') and enumerates the families covered (blog, games, practices, research, glossary, PanchaVikas). It also explicitly positions itself as the general entry point, which separates it cleanly from the narrower find_*/lookup_* siblings.

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?

Gives an explicit when-to-use rule ('when a request doesn't clearly belong to one specific family'), two concrete example queries, and names the four alternatives for when you do want a single family with server-side filtering. Both the selection case and the exclusion case are covered.

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