negative_news

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is safe and potentially partial. The description adds context about the information sources (Glassdoor, Reddit) and the type of adverse signals covered (fraud, layoffs, defaults, employee/public controversy), which goes beyond the annotations. It does not describe pagination or return format, but for a screening tool with readOnlyHint and openWorldHint, the description adds meaningful behavioral context. A 4 seems fair.

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?

Two sentences, front-loaded with the core purpose and examples of what it covers. The second sentence routes to the alternative tool. No filler. Slightly dense but highly efficient.

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 no output schema, complexity includes a nested context object with several optional fields. The description tells the agent the purpose and the source categories, and points to the sibling for legal records. It does not explain how to use optional parameters like sector, companyDomain, or listed, and does not describe output shape, but the readOnly and openWorld annotations cover the uncertainty. Complete enough for the agent to decide and invoke, though parameter usage guidance is modest.

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 description coverage is 0%, so the description must compensate. The description mentions 'a company' but does not elaborate on any of the input parameters (context, company, date, listed, sector, country, companyDomain). It does not say how the parameters influence the search, e.g., how country or listed affect the sources. Baseline is 3 when description adds some context; here it adds purpose context but no parameter-specific semantics beyond what the JSON schema already shows.

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 purpose: screens news and public-sentiment sources (Glassdoor, Reddit) for adverse media and complaints about a company, specifically for due-diligence and risk-screening. It differentiates from litigation_history by explicitly stating that hard regulatory/legal records should use that tool instead. The verb 'screens' plus the resource and context make the purpose specific and distinguishable.

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 explicitly names an alternative tool (litigation_history) and gives the condition for selecting it ('For hard regulatory/legal records... use litigation_history instead'). This leaves no ambiguity about when to use this tool versus its closest sibling.

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