breakdown

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description explains the conceptual output but doesn't disclose return format, pagination behavior, how results are ordered (beyond the query-empty browse mode), or whether results include the raw text. For a tool that returns structural analysis, the agent is left guessing about response shape and ordering semantics.

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 a tight single sentence that front-loads the core purpose. It's efficient with no wasted words. It could arguably add a touch more behavioral detail, but for its length it earns its place. Not verbose, not under-specified to the point of confusion.

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 no output schema and no annotations, plus 4 parameters and conceptual complexity (categories of structural breakdown), the description is reasonably complete on the 'what' but thin on the 'how results come back' — no ordering default beyond score-browse, no return shape, no inclusion/exclusion semantics beyond what's in the parameter docs. Adequate but with clear gaps for a moderately complex tool with zero annotation coverage.

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%, and the description adds meaningful conceptual context beyond the schema: it frames 'query' as words to search for, connects empty-query to score-based browsing (aligning with the top_rated sibling), and distinguishes include_hidden packs as 'on-rubric but judged unrepresentative' and include_restricted as 'licence bars redistribution'. The description enriches each parameter with real behavioral meaning.

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 identifies a specific verb+resource ('structural breakdowns ... for lines matching a query') and clarifies the category ('mechanism, setup/turn, technique'). It contrasts with siblings like search_humor and sources by emphasizing it's about joke construction, not text retrieval. However, it doesn't explicitly name which sibling to distinguish from, so it misses the top marks for differentiation.

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 implies the tool is a search-and-browse mechanism ('lines matching a query', 'empty = browse by score'), and the contrast with top_rated (score browsing) is hinted at. But it doesn't give explicit guidance on when to choose this over search_humor, top_rated, or sources, nor does it state exclusions or prerequisites. Usage context is implied rather than stated.

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