Knowledge base

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description usefully discloses the three access modes and the case-insensitive topic matching, but says nothing about result shape, topic granularity, or size of the knowledge base — the agent cannot tell how much text a read will return.

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?

Front-loaded with what the knowledge covers, then the invocation modes, then the when-to-use guidance — a sensible order. The content enumeration in the opening sentence is long but each item signals a distinct capability an agent might need to locate.

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 two optional params, full schema coverage, no output schema and readOnly annotations, nothing material is missing — the no-argument mode gives the agent a self-discovery path, so the absence of a topic listing in the description is not a gap.

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 coverage is 100%, so baseline is 3, but the description adds real semantics: that `query` spans every topic, that `topic` matches names as listed, and that omitting both yields a topic index. That is meaningfully more than the per-field schema strings provide.

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 resource and enumerates its contents (workflow rules, easing/timing, kinetic typography, PSD-to-animation, installed plugins/presets/MOGRTs, brand rules). This is clearly distinguished from the sibling probes (ae_comp_info, ae_layer_info) which return live app state rather than authored knowledge.

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?

Explicitly gives the selection rule: no argument lists topics, `topic` reads one, `query` searches all, plus a when-to-use directive ('read the relevant topic BEFORE planning a non-trivial animation or choosing an effect'). This is exactly the when/when-not/alternatives pattern.

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