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

With no annotations, the description carries full burden and excels. It discloses that 10b5-1 trades are aggregated separately, that only open-market buys/sells enter flow buckets, that grants/options/tax-withholding are excluded, and that as_of uses filing date rather than trade date. This is rich behavioral context beyond what any schema could 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 dense but efficient: four sentences, each earning its place. It is front-loaded with the main purpose, then explains bucketing semantics, inclusion rules, and as_of guidance. No wasted words.

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 tool with no output schema or annotations, the description covers the most critical selection and invocation nuances: grouping logic, excluded transaction types, and correct as-of usage. However, it omits response structure (aggregated vs row-level) and how start/end/limit/record_type interact, leaving minor gaps.

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?

Only 17% of schema params have descriptions. The description provides excellent semantics for as_of (filing-date filter, reproducibility, trade-date leak warning), but says nothing about start, end, record_type, or limit. The record_type enum is self-explanatory to some degree, but the description does not address it.

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 it returns 'INSIDER TRANSACTIONS SPLIT BY WHETHER THE TRADE WAS PRE-SCHEDULED' for Form 4/5 activity for one company, naming the key metadata fields (10b5-1 flag, filing lag). This is specific and distinguishes it from sibling tools like tengu_v3_intel_insider_trades or tengu_v3_intel_insider_flow_coverage.

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: it explains that 10b5-1 sales are pre-scheduled and carry no view, that the no-flag bucket is unknown rather than discretionary, and that as_of should filter on filing date to avoid leaking late-filed trades. However, it does not explicitly name alternative tools or state 'use this instead of X'.

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