get_insider_transactions

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

With no annotations, the description carries the full burden and does so well: it discloses that filings where the company is an owner of another issuer are skipped, that Form 4/A amendments replace originals in totals, and that non-P/S codes are labelled not open-market. It omits auth/rate-limit and pagination behavior, but the substantive data-handling semantics are unusually 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?

Dense but front-loaded: the resource and ordering come first, then the counting rules, then amendments/skips, then parameter detail. Some clauses (derivative flag, Rule 10b5-1 flag) border on return-value enumeration better suited to the output schema, but nothing is pure filler.

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?

An output schema exists, so explaining return values is largely redundant, yet the description still signals what each row contains. Combined with the data-exclusion semantics, an agent has what it needs to call correctly; only the `limit` semantics and any auth/rate constraints are missing.

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%, so the description must compensate. It fully documents `since` (filing date, YYYY-MM-DD, default 12 months ago) but says nothing about `limit` (schema default 50) or clarifies `ticker` format — partial compensation only, so the 3 baseline is right.

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 resource (SEC Form 4 insider transactions), the returned fields, ordering ('newest first'), and the domain rules that distinguish it from sibling filing/fundamental tools. An agent can tell immediately this is the insider-trading dataset, not general filings or price data.

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?

Implicitly scopes usage through the `since` default (12 months) and the explicit rule that only codes P and S count as open-market. It doesn't name a sibling alternative or state when NOT to use it, so it falls short of a 5.

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