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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context: the exact definition of a cluster buy, the filing code involved, the market-wide scope, and that results are sorted by total dollars. This goes beyond the structured annotations without contradicting them.

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 well-organized: a one-sentence summary, a precise definition, market universe and sort order, then an Arg list. It is slightly wordier than necessary—'one of the stronger public signals' is more promotional than operational—but every sentence contributes useful context and the parameter section is clean.

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 query tool with three optional parameters and an output schema, this description is complete. It defines the domain, explains the signal semantics, specifies the sort order, and documents all parameters with ranges and defaults. The output schema covers return values, so no further return-shape detail is needed.

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 0%, so the description must compensate for the undocumented parameters. It does so fully by explaining each parameter's purpose, allowed range, and default: days as look-back window, min_buyers as minimum distinct insiders, and limit as rows to return. This gives the agent everything needed to set meaningful values.

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 tool's output: companies with cluster buys by corporate insiders. It gives a specific definition (two or more distinct officers, directors, or 10% owners filing Form 4 code P) and distinguishes itself from Congress-only trading by saying it is market-wide. It does not use an explicit verb like 'returns' or 'lists,' and it doesn't name a sibling tool, but the resource and scope are 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 implies when to use this tool: when you want open-market insider cluster-buy signals across all companies. It also explicitly says it is 'not limited to what Congress trades,' which hints at a distinction from congress_trades. However, it does not explicitly state when to use this vs. a specific alternative, nor does it mention any exclusions or complementary 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?

Beyond the readOnly/idempotent annotations, it discloses three behavioral traits: newest-first order, legally required dollar brackets rather than exact amounts, and the already-normalized direction semantics for put purchases. These are exactly the non-obvious behaviors an agent needs to interpret results correctly.

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 front-loaded: purpose first, then key filter semantics, then a tidy Args block with one line per parameter. No wordy filler or redundant restatement of the 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?

All eight optional parameters receive adequate guidance, and the tool's output-related caveats (sort order, amount granularity, direction normalization) are covered. With annotations covering safety 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?

With 0% schema description coverage, the description fully compensates by documenting every parameter: ticker format, politician_id origin, direction values, owner values, asset_type values, date format, and limit range with default. This is more informative than the raw 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 'Stock trades disclosed by members of Congress (House and Senate PTRs)', clearly identifying the resource and data scope. It does not explicitly contrast itself with sibling tools like top_signals or member_track_record, so it stops short of full sibling differentiation.

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 gives explicit usage context by enumerating the available filters (ticker, politician_id, direction, owner, asset_type, date range) and noting that politician_id comes from `search`. It does not name alternative tools for signals or track records, but the filter list makes the tool's intended role 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 declare readOnly, idempotent, and closed-world behavior, so the description's job is lighter. It adds meaningful context about how the leaderboard is computed, including the min_trades qualification to avoid single-trade outliers and the composite-score multiplier, which goes beyond the annotation metadata.

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 purpose is front-loaded in the first sentence, followed by a compact rationale and a clearly formatted args list. Every sentence earns its place; there is no filler or repetition of schema fields.

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 two-parameter read-only query tool with an output schema present, the description covers ranking semantics, qualification threshold, score composition, and parameter constraints. Nothing essential is missing for correct selection and 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 description coverage is 0%, so the description fully carries parameter documentation. It explicitly defines min_trades with its purpose, valid range, and default, and limit with its purpose, range, and default. This is exemplary compensation for an empty 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-resource relationship: members of Congress are ranked by how often their stock buys beat SPY at 90 days. This clearly distinguishes the tool from the sibling list by naming the exact ranking metric and population.

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 usage context is implied: an agent should invoke this when a ranked leaderboard of Congress members' trading performance is needed. However, there is no explicit guidance about when to prefer this tool over siblings such as top_signals or member_track_record, and no when-not-to-use 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 declare readOnlyHint true and idempotentHint true, so safety profile is covered. The description adds valuable behavioral context: measurement window (first close after disclosure, 30/60/90 days), comparison against SPY, meaning of weight_in_score, and treatment of sales. 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?

Description is compact and front-loaded with purpose, then methodology, then parameter guidance. Every sentence contributes; 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 output schema exists and annotations cover read-only behavior, the description is sufficient. It covers purpose, measurement methodology, and parameter semantics. Minor gaps like error handling are not necessary because of output 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 0%, so description carries full parameter documentation burden. It adds meaning beyond schema: politician_id sourced from search, recent_trades defined as measured buys with range 0-50 and default.

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?

Description states a specific verb+resource: it evaluates how a member's disclosed stock trades performed, with defined measurement methodology. It distinguishes from sibling tools like search and leaderboard by focusing on individual member trade performance.

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?

Description clearly implies usage: to get performance of a specific member's trades, and references 'search' as source of politician_id. It does not explicitly compare against alternatives or state when-not-to-use, 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?

Beyond the readOnly and idempotent annotations, the description adds useful behavioral detail: the model reads daily disclosures, makes 3–5 calls with specific fields, and scores them against SPY like member trades. This enriches the agent's understanding of the data and its provenance.

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 efficient and well-organized: a clear opening statement, a concise explanation of the model's process, and a focused Args section. No redundant or filler content.

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 the simple parameter surface (one optional arg), rich annotations, and the presence of an output schema, the description sufficiently covers the tool's purpose, behavior, and parameter semantics. Nothing critical 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?

The schema has zero description coverage, but the description fully documents the history parameter: range 0–100, default 0, and ordering (newest first). This is essential for correct invocation and completely compensates for the schema 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?

The description clearly identifies the tool as returning the site's AI model's morning brief and directional calls with scoring, and explicitly differentiates it from a forecast ('scorecard of the model, not a forecast'). This distinguishes it from sibling tools like top_signals or signal_outcomes.

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 interpretive guidance ('treat it as a scorecard of the model, not a forecast') but does not explicitly state when to use this tool over siblings or provide exclusions. An agent must infer its comparative utility.

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. The description adds useful behavioral detail beyond that: matching is case-insensitive and partial, and it returns identity data needed by other tools. It does not contradict annotations and covers the observable matching behavior.

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 two short paragraphs plus an Args block, with the main purpose front-loaded. Every sentence contributes either the primary action, the workflow position, matching behavior, or the parameter rule.

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 lookup with an output schema and read-only/idempotent annotations, the description provides everything an agent needs: what to search, why to search, how matching works, and the query constraint. The output schema covers return structure.

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 carries the full burden. It explains that query accepts a name or ticker fragment and imposes a 1-80 character range, giving an agent enough semantic detail to construct a valid call.

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 action ('Find') and a clear resource set: members of Congress, tickers, and Federal Reserve officials, searched by name or symbol. It differentiates itself from the sibling tools by framing it as the resolution step that produces the politician id or exact symbol the other tools consume.

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 gives an explicit trigger: use this first when you have a name or ticker fragment and need an ID/symbol. It does not name a specific alternative or list when not to use it, but the first-use instruction makes the intended workflow 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 readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral context beyond that: results are per scoring regime version, default to the current version, and small `total`s signal a young regime that should be flagged. It also explains the data flow (daily snapshots paired with future price moves), which is genuinely useful for interpreting 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 front-loaded with a clear purpose, then provides a concise mechanism explanation, a caveat about young regimes, and a dedicated Args section. Every sentence adds information relevant to selecting or invoking the tool, with no filler or repetition of schema fields.

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 the output schema exists and there is only one optional parameter, the description is complete: it explains conceptual purpose, data provenance, per-version behavior, default parameter handling, and an interpretive caveat. No critical information needed to call the tool correctly 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?

Schema description coverage is 0%, so the description carries the full explanatory burden for score_version. It does so by stating the parameter restricts results to one scoring regime and defaults to the current one. This is sufficient for a single optional parameter, though it could have added a bit more detail on how versions are identified.

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 a specific function: computing hit-rates for every score bucket at 30/60/90 days. It explains the underlying snapshot-and-price mechanism and frames the output as a scorecard of per-label resolved snapshots and win rates. This is distinct enough to separate from sibling tools like top_signals or ticker_signal, even without naming them.

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 opening question 'Does a label actually go up?' and the description of the scorecard give clear context for when to use this tool: when an agent needs outcome validation per score label over 30/60/90 day horizons. It does not explicitly name alternatives or exclusion cases, but the use case is clearly scoped.

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 it readOnly and idempotent, and the description adds meaningful behavioral context: the 0-100 formula, label/signal semantics, and the condition that not all tickers are eligible. No contradiction 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?

Every sentence earns its place: a one-line summary, the scoring rule and output buckets, an important eligibility boundary, and the argument definition. Front-loaded and free of 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?

For a read-only single-ticker lookup with an output schema already present, this description covers the meaning, composition, output labels, eligibility condition, and parameter format. 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?

Schema coverage is 0%, so the description must carry the parameter meaning. It does: 'ticker: Exact symbol, e.g. NVDA' adds precision that the bare schema string lacks. This is sufficient for a single 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 resource ('InsiderTrack's composite score for one ticker') and a clear verb implied ('get'/'return'). The 'for one ticker' scope and signaled outputs ('label', 'signal') set it apart from siblings like top_signals or leaderboard without needing to open them.

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?

Clear context: this tool answers single-ticker signal questions and explicitly notes that only tickers traded by a tracked member of Congress will have a score. It does not name sibling alternatives or state when not to use it, but the boundaries are clear enough 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?

Annotations already cover readOnlyHint and idempotentHint, so the description does not need to restate safety. It adds modest context: the results are a current snapshot, sorted highest first, and constrained by limit/min_score, but does not disclose deeper behavior such as data age or scoring source.

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 purpose is front-loaded in one sentence, followed by compact, scannable parameter lines. There is no filler or repetition of schema fields.

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 simple ranked-list tool with an output schema, the description is complete: the agent knows what it returns, how it is ordered, the parameter constraints, and the sibling to use for underlying reasons.

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?

With 0% schema description coverage, the Args section fully compensates: limit is described with range (1-25) and default (10), and min_score is described as a 0-100 threshold. This adds real meaning beyond the bare type/default fields in 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 first sentence states a specific, scannable purpose: returning 'the strongest composite scores right now, highest first.' It also distinguishes itself from the sibling ticker_signal by directing reason-seeking users there.

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 when not to use this tool and where to go instead: 'use ticker_signal for the reasons.' It does not discuss other siblings like search or leaderboard, but the most confusable alternative is handled.

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