feeds

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

With no annotations available, the description carries the full behavioral burden and does a good job: it explains the three timestamp fields, the ~45-day STOCK Act disclosure delay, and the key limitation that Senate data is parsed to ticker level while House filings are metadata only. It does not cover rate limits, pagination, or return formatting, but the most decision-relevant behaviors are disclosed.

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 appropriately sized at four sentences, each serving a distinct purpose: scope/source, field definitions, temporal semantics, and data-granularity caveat. It is front-loaded with the primary function and contains no filler or repetition. This is a model of concise, information-dense documentation.

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 four optional filters and no output schema, the description provides the return record fields and critical data-quality caveats, which is sufficient for an agent to invoke it correctly. The main gap is the absence of pagination, result limits, ordering, or a note about what 'metadata only' means for House records, which prevents a perfect score.

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 schema already describes three of the four parameters (name, since, ticker), leaving chamber with only enum values. The description adds important semantic nuance beyond the schema: the Senate-vs-House granularity difference affects how ticker and chamber filters behave, and the disclosed_at guidance clarifies the intended meaning of since for temporal filtering. This goes beyond the structured schema coverage.

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 identifies the resource (US Congress stock transactions) and its sources, and implies a query/list operation even though no explicit verb like 'list' or 'get' is used. The domain (Congress) and mention of Senate vs House data distinguish it from the sibling tools focused on ETF flows and insider trades, though that contrast is not explicitly stated.

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 no explicit 'when to use this vs alternatives' guidance. However, it implies the intended use case through domain-specific context, and it offers concrete usage advice about using disclosed_at rather than happened_at for point-in-time work. No exclusions or alternative tool names are mentioned, so usage guidance is mostly implied rather than direct.

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

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

With no annotations, the description carries the full burden, and it delivers rich behavioral detail: it explains that price moves are removed, that the series cannot be backfilled, that every row was banked on its existing day, and that span_days above 1 flags gaps. This goes well beyond a simple 'returns flows' statement.

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 compact and impactful. It leads with the core definition and computation, then adds necessary caveats about backfilling and gap handling. Every sentence earns its place with no 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?

Given no annotations and no output schema, the description covers the essential behavioral caveats and the meaning of span_days. It could be marginally more complete by describing the full row structure or default time range, but it is sufficient for selecting and invoking the tool.

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 100%, with both since and ticker documented in the schema. The description adds useful context about output semantics like span_days, but it does not add meaning to the parameters themselves beyond what the schema already provides.

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 names a specific resource—spot bitcoin ETF creation/redemption flows—and explains the precise computation (change in shares outstanding times NAV). This clearly distinguishes it from the sibling tools, which cover congressional trades and insider transactions.

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 domain is clearly ETF flow data, so the use case is evident relative to the sibling tools. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it.

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

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

With no annotations, the description carries the full burden and covers key behavior: it discloses the observed_at and happened_at fields, explains the exclusion rationale, and details the 13D/13G inclusion with direction semantics. It does not mention output format or pagination, but the essential behavior is transparent.

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 a single dense paragraph, but each sentence adds distinct value: purpose, exclusions, data fields, alternative tool, and the 13D/13G extension. It is front-loaded with the core definition and remains readable despite its length.

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 four parameters and no output schema, the description covers the essential: what data is returned, what is excluded, how to filter, and the alternative tool. It could mention pagination or default date range, but the core context is complete for selecting and invoking the tool.

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 75%, so the schema already documents most parameters. The description adds meaning to form by explaining 13D vs 13G and direction=buy on initial filing, and notes min_value only applies to Form 4 rows. It does not add to since/ticker but they are self-explanatory.

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 defines the tool as listing SEC Form 4 open-market insider buys, with explicit exclusion of compensation events (grants, options, etc.). It distinguishes itself from insider_sells by naming it as the alternative for disposals, making the purpose unmistakable.

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?

It explicitly says 'For disposals use insider_sells', providing a direct when-not-to-use instruction. It also explains the form parameter for filtering 13D/13G and notes that form=4 restricts to Form 4 only, giving clear context for selection.

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

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

With no annotations, the description carries the burden and does so well: it discloses the data source, the code-S filter, the observed_at vs happened_at distinction, the 13D/13G direction computation, and the min_value caveat. It stops short of describing output ordering or pagination, but those are minor for a read-only SEC data 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?

Every sentence earns its place: purpose, filtering rule, interpretive caveat, key date fields, sibling routing, and secondary 13D/13G behavior are packed without filler. The most important scope statement is front-loaded.

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 and no annotations, the description is thorough about input semantics and result fields. It leaves out explicit output structure/pagination, but the agent has enough to select and call it correctly with optional filters.

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 already covers 75% of parameters, and the description adds real semantics: form values map to filing types, min_value only applies to Form 4 rows, and 13D/13G direction is relative to the last filing seen. Ticker remains undocumented in both schema and description, which is the only gap.

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 the exact scope: SEC Form 4 open-market insider sells (code S only), plus Schedule 13D/13G stake decreases and sub-5% exits. This clearly differentiates the tool from insider_buys and from generic trade lists.

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?

Explicitly routes acquisitions to insider_buys, warns that sells carry less signal than buys, and explains how to restrict to Form 4 with form=4. The agent knows when and when not to invoke this tool.

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

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

With no annotations, the description fully carries the burden. It discloses data provenance (from chain logs, no backfill), timing definitions (happened_at vs observed_at), and clarifies that buyers are transaction senders, not the router. This is thorough and unambiguous.

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 a single dense paragraph, but each sentence adds necessary context. It front-loads the primary purpose and then details the data specifics. Slightly longer than ideal but appropriate for the tool's complexity, with 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 7 optional parameters and no output schema, the description is exceptionally complete. It explains the chain, the filtering threshold, the cohort composition, grading metrics, launchpad identification, and data collection timing. An agent can confidently invoke it without additional documentation.

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 100%, so the baseline is 3. The description adds context about what the results mean (e.g., early-buyer definition) but does not elaborate on parameter syntax or format beyond the schema. It provides marginal added value over the schema.

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: token launches on Robinhood Chain with a first-hour activity floor, including early-buyer cohort details. It clearly distinguishes from siblings like congress_trades or insider_buys by its unique focus on chain-specific launch 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?

The description provides clear context on the data scope and filtering criteria, implying when it is relevant. However, it does not explicitly name alternatives or exclusions (e.g., when to use launch_wallets instead), so it lacks the explicit routing found in top-tier examples.

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

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

With no annotations, the description carries full behavioral burden and does so well: it defines hit rate and dead rate precisely, notes the feed is recomputed at each publish from a forward-only ledger, and explicitly states it ranks rather than recommends. This gives the agent strong expectations about data freshness and interpretation.

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: source derivation, field semantics, metric definitions, intended use, and recomputation behavior. It is appropriately sized for a tool with no output schema.

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?

Because there is no output schema, the description compensates by enumerating the output fields and defining the key metrics. It does not specify result ordering or pagination, but the 'ranks' statement implies ordering and the optional filter params are fully documented in the schema.

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 100%, so the baseline is 3; the description does not add parameter-level detail beyond what the schema already provides, but it does provide useful context like 'early-buyer cohort' and 'early in' that informs how filters like min_launches and ticker relate to the data.

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 identifies the resource as a wallet book derived from launch_ledger, enumerating the exact fields each wallet entry contains. It is clearly a wallet-level counterpart to the sibling launch_ledger, though it lacks an explicit action verb like 'list' or 'get'.

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?

It provides clear context: repeat early buyers with high hit rates are the cohort worth watching, and the feed ranks rather than recommends. It does not explicitly state when to prefer this over launch_ledger or other siblings, but the derived-from relationship makes the distinction reasonably clear.

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