Find a Sun Tzu quote for a situation

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

With no annotations, the description must carry the behavioral disclosure itself. It states that results are verses with chapter citation, ordered best match first, and gives input-pattern examples. It doesn't address no-match behavior or side effects, but the disclosed behavior and return ordering provide solid transparency for a simple search tool.

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?

Three sentences carry purpose, usage examples, output format, and an alternative-tool pointer without repetition. The examples are substantive rather than padding, and the most important verb/resource phrase is front-loaded.

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 search tool with no annotations or output schema, the description covers the essential user journey: what it returns, how to phrase input, and where to go for an alternative workflow. It wisely leaves parameter detail to the schema; the only omission is explicit error/no-result handling, but that is not core to selecting the tool.

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 fully documents all three parameters (count, theme, situation) at 100% coverage, so the baseline is 3. The description adds value by instructing users to describe the situation 'in plain words, including how it feels' and offering concrete example phrases, which clarifies the intended input format beyond the schema's generic 'plain language' note.

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 opening sentence is specific: 'Finds the Art of War verses that fit a described situation,' naming both the resource (Art of War verses) and the action (semantic matching). It explicitly distinguishes from the list_themes sibling with the caveat about browsing vocabulary, and the 'fit a described situation' phrasing clearly separates it from random_quote.

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 concrete when-to-use guidance through examples of situations ('PM keeps adding scope...') and advises using list_themes first if the user wants to browse vocabulary instead of describing a situation. This is an explicit alternative, satisfying the when/when-not requirement even though random_quote and quote_card are not named.

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