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

With no annotations, the description must disclose behavior. It describes what the tool contains (the techniques) but not how it behaves operationally—e.g., that it returns a list or filtered set rather than performing a search. There's no mention of output format, filtering behavior, or that it is a reference repository. The description focuses on content value but leaves the operational mechanics implicit.

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 three sentences, front-loaded with the core purpose and key specifics. It includes concrete details (39 techniques, local-language strategies) without fluff. It is compact yet informative, though slightly longer than necessary. No redundant phrases.

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?

Given it's a reference tool with no output schema, the description covers its purpose, content, and usage timing. It explains what an agent will get (techniques with queries) and why they work. It doesn't specify the exact return format, but that's implicit as a list of techniques. The description is adequate for an agent to decide when to call it and what to expect.

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 schema already provides 100% coverage with descriptions for both parameters. The description adds context by connecting the market parameter to local-language strategies for JP/KR/CN markets, which helps an agent understand when to set specific market values. It does not repeat the schema but enhances understanding of how market relates to the tool's purpose, so it exceeds the baseline of 3.

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 identifies the tool as a collection of 39 search techniques for games research, each with a pasteable query, what it surfaces, and why it works. It differentiates itself from siblings like search_sources and get_landscape by positioning itself as a pre-search reference, not a direct search or data retrieval tool.

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 instructs to use it 'before searching the open web on a games question' and highlights that it contains queries that reach buried material. It also mentions local-language strategies for specific markets. It doesn't explicitly contrast with alternatives, but the 'use this before' instruction gives clear temporal context for when it should be invoked.

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