red_flag_screen

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

Beyond the readOnly and idempotent annotations, the description adds important behavioral context: the tool only aggregates supplied evidence, never fabricates new evidence, and does not render an investment verdict. It also explains the optionality behavior, making the tool's operational boundaries clear.

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 dense but every sentence earns its place: it defines the output, names the evidence sources, clarifies non-invention and non-verdict behavior, and explains optionality. It is front-loaded with the core purpose and avoids redundant phrasing.

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 aggregation purpose, severity buckets, overall severity, source traceability, and optional inputs. Since there is no output schema, the description does most of the work, though it stops short of describing the exact flag object structure or threshold logic; monthsSinceLastFunding is also left unexplained.

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 usefully maps several parameters to their upstream tool outputs, such as litigationCases from litigation_history and negativeNewsCount from negative_news. However, monthsSinceLastFunding and companyName receive no semantic explanation in either the schema or the description, leaving a noticeable gap for those parameters.

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 states a specific verb and resource: it aggregates already-gathered evidence into a severity-bucketed flag list. It names the upstream tools and explicitly clarifies that it invents no new evidence and renders no investment verdict, which clearly distinguishes it from other research and report-generation siblings.

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 clear context for when to use the tool: after evidence has been collected from litigation_history, negative_news, ratio_analysis/financial_statements, and promoter_background. It also states that all inputs are optional and that omitted categories contribute no flags, which is practical selection guidance, though it does not explicitly name exclusions or alternatives.

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