Livermore

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

The annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds useful context: ISO 8601 UTC timestamps, update schedule, unavailable datasets, and server usage limits. It does not contradict the annotations, though it reads more as a contents list than a deep behavioral contract.

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 one dense sentence, but it is front-loaded with 'What data Livermore has and how fresh it is' and every listed item adds relevant context. It could be split into shorter sentences for readability, but nothing is wasted.

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 no-argument, read-only metadata call with an output schema, this is complete: it explains what data is covered, freshness details, update schedule, known gaps, and usage limits, and it tells the agent when to call it.

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?

There are zero parameters and the schema is empty, so the description cannot add parameter-level detail. It appropriately uses its space to describe what the endpoint reports rather than parameter syntax.

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 names the resource ('data coverage and freshness') and uses a specific verb ('get'), then enumerates exactly what is reported: Form 4 ranges, 13F quarters, superinvestor counts, and update schedule. This makes it easy to distinguish from sibling data-query tools like get_insider_trades or get_stock.

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 gives an actionable trigger: 'Call it to check whether a date or quarter is covered.' It does not name sibling alternatives or state when not to use it, but for a metadata/coverage endpoint the intended usage is clear.

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?

Annotations already indicate read-only and idempotent, so the description does not need to repeat that. The description reveals useful behavioral constraints: non-derivative transactions only, row filtering for price outliers and duplicate filings, and exclusion of issuers without a ticker. It also specifies the output is in USD and limited to 200 rows, which adds transparency beyond annotations.

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 reasonably concise, packing a lot of information into a few sentences. It is front-loaded with the core purpose, then details the lists, and finally the technical constraints. There is some redundancy with the schema (repeating list names), but overall it is efficient.

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 is fairly complete for a read-only tool with a simple output schema. It explains the filtering rules, the meaning of windows, and the row limitaving. The only possible missing context is the exact field list for the returned trades, but it references get_insider_trades for that, so an agent can look it up. This is sufficient.

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 input schema already provides a comprehensive description for each parameter: the 'list' parameter has an enum with all allowed values and a description repeating them, and the 'limit' parameter has range and default. The description adds clarity by explaining what each list returns and the underlying logic, but it doesn't add new semantic meaning to the parameters themselves. Given 100% schema coverage, a baseline of 3 is appropriate.

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 the tool's purpose: provides ready-made insider trading screens with specific list names and their definitions. It references the livermore.club website and explicitly lists all six screen types, making it evident what each list returns. This goes beyond a generic statement of 'get insider 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?

The description explains the meaning of each list and the criteria (e.g., cluster-buys, ceo-cfo-buys, top-buys-week etc.), which helps agents select the appropriate list. It also notes that windows count back from now by SEC filing time and provides details on transaction types. However, it does not explicitly mention when to use this tool versus alternatives like get_insider_trades, but the context is clear enough.

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?

Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavior: row consolidation semantics, value weighting, price outlier handling, backfilled filing date caveats, rule_10b5_1 null behavior, URL fields, and a 200-row pagination cap. This is far beyond the annotation baseline.

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 long but densely packed and front-loaded with the core purpose, then row semantics, constraints, codes, dates, outliers, and pagination. Each clause earns its place and no words are wasted.

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 10-parameter, 0-required tool with an output schema, the description is unusually complete: it covers defaults, edge cases, date/timezone details, code meanings, outlier flags, pagination, and returned fields. An agent has everything needed to invoke it 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?

Although schema description coverage is 100%, the description enriches every parameter group: it explains the meaning of transaction codes, the date format and timezone handling, the scope of ticker and insider_cik filters, and the impact of min_value_usd. This adds real selection value beyond 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 opens with 'Insider transactions from SEC Form 4 filings,' naming a specific verb, resource, and data source. It clearly differentiates from sibling tools like get_stock and get_insider_lists by focusing on Form 4 filing 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 description gives concrete usage context: it explains market-wide queries require a 30-day window, defaults to 7 days, and defaults to P/S codes. It doesn't explicitly name alternative tools, but the operational guidance is clear enough for an agent to decide when to call this endpoint.

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?

The description discloses substantial non-obvious behavior beyond the annotations: portfolio value excludes options, changes and sold-out positions are omitted if the prior quarter was not filed, ticker-less securities have null URLs, and the hard cap of 200 holdings with pagination. This is exactly the kind of context that helps the agent anticipate results.

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 dense single paragraph, but nearly every clause carries distinct information and there is no filler. It is front-loaded with the core resource, though its run-on structure prevents it from being a model of concise clarity.

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 this complexity, the description covers all major output areas: identity, quarter history, holdings, changes, sold-out positions, options, valuation edge cases, and pagination. The output schema still exists to carry formal return structure, but the description leaves no major practical gap.

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 100%, which sets a baseline of 3. The description adds meaningful behavior around the quarter parameter (defaults to latest filed quarter) and clarifies pagination/output semantics like pct_of_portfolio and share change, so it earns one point above baseline.

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-resource relationship: it retrieves one 13F filer by SEC CIK and details the names, quarters, holdings, sold-out positions, and options. It is clear and specific, but it does not explicitly contrast this tool with siblings like get_stock_13f_holders or get_superinvestor_activity, so it stops short of a 5.

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 guidance on when to choose this tool over alternatives or when not to use it. It mentions defaults and a pagination instruction ('use page'), but that is operational details, not usage context or exclusions.

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?

Annotations already mark the tool as read-only and idempotent, and the description adds non-obvious behavioral details: the 90-day insider lookback, latest complete versus in-progress quarters, and the reason share classes are treated as separate tickers. This is valuable context beyond the annotations, with no contradiction.

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 organized by data category, with the core purpose front-loaded. It is longer than the minimum, but each clause carries meaningful distinguishing information, so the length is justified.

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 tool's scope, data definitions, edge cases like share classes and in-progress quarters, and explicitly routes to sibling tools for more detailed lists. With an output schema present and read-only annotations, an agent has everything needed to invoke this 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 100%, and the single ticker parameter is already well-described with examples and dot-notation handling. The description reinforces that share classes are separate tickers and that the stock must be US-listed, but it adds little 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 opens with 'Overview of one US-listed stock' and enumerates the exact data sections returned: company facts, insider activity, 13F ownership, and superinvestor holdings. It also distinguishes itself from sibling full-list tools by explicitly naming get_insider_trades and get_stock_13f_holders.

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 sets clear scope ('US-listed stock', one ticker) and provides explicit routing guidance: 'Use get_insider_trades and get_stock_13f_holders for the full lists.' The quarter-completeness note also sets expectations about data freshness, which helps an agent decide whether this overview is sufficient.

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?

Description adds rich behavioral detail far beyond the annotations: sold_out vs not_filed ordering, CUSIP combining, changes_available false condition, totals covering all holders, pagination cap. Annotations already declare read-only/idempotent, so the description's extra nuance about data structure and edge cases is valuable and non-contradictory.

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 long but highly information-dense; every clause serves the agent (sold_out handling, not_filed semantics, change availability, pagination). It is front-loaded with the core purpose and then systematically covers edge cases, making it efficient 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?

With an output schema present, the description correctly explains output-specific nuances (sold_out, not_filed, changes_available) that the schema cannot convey. It covers all behavioral caveats an agent needs to correctly interpret results and paginate.

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 a baseline of 3 is appropriate. The description does not add meaning beyond what each parameter's schema already states; it mentions pagination and has_more but that is output-related. The ticker format example (BRK.B) is already in the schema description, so no extra lift.

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-resource pair ('Institutions that reported holding a stock in their 13F-HR filings') and immediately scopes it to one calendar quarter and US-listed long positions. It clearly differs from siblings like get_insider_trades or get_institution, even without naming them, because the 13F-HR focus is unambiguous.

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 strong context on when the tool is applicable: default quarter, filing delay, coverage scope (US-listed long positions). However, it does not explicitly name alternative tools or state conditions for using a sibling instead. This is a minor omission given the highly specific name and scope.

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?

Annotations already establish read-only/idempotent behavior. The description adds valuable behavioral context beyond that: comparison basis (share count not value), security merging (ticker/CUSIP), filing delay (45 days after quarter end), and the grouping/ordering of individual moves. No contradictions with annotations.

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 longer than average but every sentence contributes: it covers purpose, both modes, comparison rules, data source, and timing. The front-loaded purpose sentence orients the agent immediately, and the subsequent detail is organized logically. Slightly dense but not wasteful.

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 read-only, idempotent data retrieval tool with a full output schema and 100% parameter coverage, the description covers all agent-relevant details: default behavior, variant behavior, data merging, comparison criteria, and data freshness. Nothing essential is missing for correct invocation.

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 100% so parameters are already documented. The description adds extra meaning: it explains what changes when superinvestor_cik is provided (grouped by action, largest positions first, shares_change_pct in percent) and clarifies that quarter defaults to the latest comparable quarter. This exceeds the schema explanations.

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: 'what the curated superinvestors bought and sold in one quarter according to 13F'. It also distinguishes from siblings like get_insider_trades (insider trades, not 13F) and get_stock_13f_holders (single stock holders, not quarterly changes). The two modes (with/without superinvestor_cik) are clearly laid out.

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 explains when to use each mode (default summary vs. individual moves with superinvestor_cik) and caveats like 'only superinvestors that filed both quarters are compared'. It does not explicitly name sibling tools to avoid, but the context is clear enough for an agent to select this over other 13F-related tools.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so safety is covered. The description adds meaningful behavior beyond annotations: sorting by portfolio value, exclusion of options, Chinese name fields, and the predecessor CIK behavior. It does not contradict annotations, and the added context enriches the agent's understanding without relying on the schema.

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 each sentence earns its place: main purpose, data fields, sorting, naming, predecessor CIK, and alternatives. It is front-loaded with the primary function and avoids redundancy. Slightly long but not wasteful.

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?

With no parameters and an output schema present, the description covers all essential call-time information: what data is returned, sorting, edge case of source_cik, and pointers to sibling tools. It does not mention pagination or rate limits, but those are less critical given the tool's simplicity and the output schema's coverage.

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 tool has zero parameters, so the baseline is 4. There is nothing for the description to add beyond what the schema provides (which is empty). The description appropriately explains the data structure instead, which is not parameter-related. No issues.

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+resource: 'list the curated list of superinvestors' with detailed data fields (portfolio value, positions, filing date, top holdings). It clearly distinguishes from siblings by mentioning get_institution and get_superinvestor_activity for different needs, so an agent can tell it apart.

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 directs when to use alternatives: 'Use get_institution(cik) for full holdings and get_superinvestor_activity for what they bought and sold in a quarter.' Also explains the source_cik caveat, leaving no ambiguity about when to use this tool versus siblings.

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?

Annotations already mark the tool read-only and idempotent, and the description goes beyond that with rich behavioral detail: per-group limits, best-match-first ordering, exact/prefix matching rules, minimum name length, Chinese-name support for superinvestors, and the meaning of the detail field. This gives an agent a strong model of how the tool behaves.

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 not wasteful; each sentence adds a distinct fact about scope, result shape, identifiers, matching behavior, or output fields. It is front-loaded with the core purpose and organized logically, making it easy for an agent to parse.

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 multi-entity search tool, the description covers the full contract: searchable entity types, supported input forms, matching rules, output limits, field semantics, and the identifiers required by sibling tools. With a read-only annotation and an output schema present, nothing essential is 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?

The schema already documents query and limit, but the description adds substantial meaning: matching by ticker prefix, exact CIK/CUSIP matching, needing at least 2 characters for names, examples like 'Buffett' and 'Pershing', and what limit means per group. This is far beyond the baseline for full 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 states what the tool does: it finds US stocks, 13F institutions, and corporate insiders by ticker or name. It also distinguishes itself from sibling get_* tools by emphasizing that it returns the identifiers those tools consume, so an agent can tell search from get_stock, get_institution, and get_insider_trades.

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 makes the tool's role as a lookup/search entry point clear: it returns ticker and CIK identifiers expected by the sibling tools. It also explains behavior such as matching superinvestors by fund or manager name and matching CIKs/CUSIPs exactly. It does not explicitly state when not to use it or compare it with alternatives like list_superinvestors, which prevents a 5.

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