industry_overview

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

The description uses the verb 'Retrieves', which is consistent with the readOnlyHint annotation and implies no side effects. It adds context about the nature of sources but does not disclose additional behavioral aspects such as rate limits, error handling, or data completeness beyond what annotations already provide.

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 two sentences long, front-loaded with the primary action and purpose. It efficiently lists content areas and sources without unnecessary verbosity, maintaining clear structure and readability.

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?

The description covers the core function and gives usage hints for the main parameters, but it omits details on other parameters like country or listed and does not mention geographic scope or output format. While not critically incomplete for a research retrieval tool, it could be more thorough given the nested context object.

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 description only elaborates on two of the six parameters inside the context object (sector and company), explaining when to pass them and the fallback behavior. It does not mention date, listed, country, or companyDomain, leaving their semantics solely to the schema descriptions. Given the low schema description coverage, the description should have compensated but only partially does.

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 states the tool's function: 'Retrieves macro/industry-level research' and specifies the content (market structure, key players, growth drivers, TAM/market size) and sources (top-tier consulting/research). It also explains its purpose as providing the industry-wide context for a company-specific report.

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 provides usage guidance by instructing to 'Pass context.sector when known for a sharper search' and explaining the fallback to company's industry. However, it does not explicitly state when to prefer this tool over alternatives like company_overview or market_size, nor does it give clear when-not-to-use conditions.

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