detect_accounting_red_flags

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

With no annotations, the description carries the behavioral disclosure burden. It adds meaningful context: data-source limitations (no Yahoo Finance related-party data), methodological boundaries (no reliable depreciation basis), and interpretative guidance ('Flags are observations to investigate, not accusations'). It doesn't explicitly state read-only behavior, but that is inherent for a scan/analysis tool.

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 front-loaded with the core action, followed by a scannable red-flag list, then exclusions and an interpretation note. Every sentence serves a purpose, and even the 'scoped out rather than faked' aside adds valuable context without bloat.

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?

For a single-parameter analysis tool with an existing output schema, this description is complete: it defines the scope, names concrete red flags, states limitations, explains output semantics, and gives input format examples. An agent has enough information to select and invoke the tool correctly.

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 0%, but the description documents the single symbol parameter with concrete examples ('RELIANCE', 'TCS.NS', 'TCS.BO') and clarifies the target market (NSE/BSE-listed Indian equity). This adds meaning beyond the bare schema definition and is sufficient for one simple parameter.

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?

States a specific verb 'Scan' and a precise resource: an NSE/BSE-listed Indian equity's most recent fiscal year. Enumerates concrete red-flag patterns (margin swing, debt spike, goodwill/intangible growth, exceptional items) and explicitly lists what is out of scope, making it clearly distinguishable from sibling analysis tools.

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 clearly delimits what the tool covers and does not cover, explaining why related-party transactions and depreciation-pattern analysis are excluded. It does not name an alternative sibling or explicitly state 'use this when...', but an agent can infer the appropriate context from the scoping and exclusions.

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