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 readOnlyHint and idempotentHint, but the description adds meaningful behavior beyond those: the 13F public-date timing, 30/60/90-day measurement windows, the meaning of `window`, and the `measured: false` outcome for funds without enough history. This is substantial behavioral context that an agent cannot infer from annotations or the empty input 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 compact and front-loaded: the core purpose is in the first sentence, followed by the most important measurement nuance and a pointer to the sibling detail tool. Every sentence adds distinct value, and the structure moves from high-level purpose to operational detail without repetition.

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 zero parameters, an existing output schema, and read-only/idempotent annotations, the description covers everything an agent needs to decide whether to call this tool. It explains the ranking methodology, data timing, eligibility caveats, and where to get more detail, making the definition self-sufficient 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 input schema has zero parameters, so the baseline is 4 because there are no parameter semantics to document. The description goes further by defining `window` as the longest horizon with data, which likely corresponds to an output concept and helps interpret results. There is no missing parameter documentation to penalize.

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 a precise statement: 'Institutional investors (13F filers) ranked by how their position changes performed vs SPY.' This names the subject, the action, and the comparison benchmark, making it clearly distinguishable from siblings like leaderboard or fund_track_record. It also immediately clarifies what the tool measures rather than just restating the name.

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 results are meaningful, noting a fund needs two loaded quarters and that early on only a few are ranked, which guides expectations. It also explicitly points to a sibling, 'Use fund_track_record for the detail,' providing a concrete alternative. It does not enumerate other alternatives or edge cases, but the context it gives is useful and 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?

The annotations provide the read-only and idempotent safety profile, while the description adds important behavioral nuance: measurements are anchored to the 13F public date, sales are evaluated in the inverted sense, and windows with zero resolved data are explicitly called out. This goes well beyond what annotations alone convey.

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: purpose, definitions/caveats, then parameters. Each section adds value, but the text is somewhat dense and the stray 'n' reference could be simplified or aligned with the actual parameter name.

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 read-only annotations and the presence of an output schema, the description covers the essential conceptual model, parameter sourcing, and edge-case behavior. Small gaps—no explicit alternative routing and the ambiguous 'n' reference—keep it from being fully complete.

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 burden for parameter meaning. It explains holder_id's provenance and gives recent_changes a range and default. The cryptic 'Windows with n 0' phrasing is ambiguous and weakens an otherwise solid parameter explanation.

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 ('one institutional investor's 13F position changes') and the benchmark ('vs SPY'), and it explains buys/sales semantics. It lacks an explicit performative verb like 'returns' or 'computes' and does not directly distinguish itself from sibling track-record tools, so it falls just 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 first sentence establishes a clear use case, and the Args section tells the agent where to obtain holder_id ('From fund_leaderboard or search'). It does not explicitly state when not to use this tool or point to alternatives, but the context is clear enough to guide 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 safety (readOnly, idempotent, closed-world), and the description layers on real behavioral context: the 45-day legal threshold that defines "late," the fact that lateness is usually one big catch-up report rather than many, and that a multi-year "longest" delay may be a filing typo checkable via the returned link. It also pre-empts a likely misinterpretation, which is exactly the kind of disclosure annotations cannot 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?

Front-loaded with the definition and the 45-day rule, then output shape, then caveats, then args — a sensible order with no filler. It runs a bit long, and the caveat sentences serve response framing as much as tool selection, but each one carries non-obvious information rather than restating structured 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?

Only two optional parameters, an output schema is present so return values needn't be described in detail, and annotations cover the safety profile. The description still explains the ranking's components and the caveats around interpreting them, leaving nothing an agent needs in order to call it correctly or frame the result honestly.

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 burden and does: days is bounded 1-3650 and omitting it means all history; limit is bounded 1-50 with a stated default of 15. Both parameters gain range, default, and semantic meaning that the bare schema does not supply.

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?

Names a specific population (members of Congress who disclose trades after the STOCK Act deadline) and states exactly what the tool produces: a ranking by count of late trades with share-late, report counts, typical and longest delay, and a link to the worst filing. That is clearly distinct from siblings like congress_trades (raw trades) and member_track_record (performance), so an agent can pick it without opening the schema.

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?

Gives concrete usage guidance for the scope parameter ("omit for all history") and, unusually, interpretive guidance: late filing is a disclosure failure, not evidence of insider trading, and the agent should say so if the user implies otherwise. It doesn't explicitly name which sibling to use instead for other trade questions, so it falls short of a full when/when-not routing statement.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral detail: matching is case-insensitive and partial, with concrete examples. This tells the agent how querying will behave, though it does not discuss result limits or ordering, which are minor given the output schema exists.

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 well-structured: purpose first, usage context second, matching behavior with examples third, and parameter spec last. Every sentence contributes necessary decision-making information with no filler or repetition.

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 search tool with an output schema and read-only, idempotent annotations, the description provides the necessary purpose, usage trigger, matching semantics, and parameter constraints. There is no material missing information an agent would need to choose and call the tool successfully.

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?

Despite 0% schema description coverage, the description fully compensates by defining the single parameter: 'A name or ticker fragment, 1-80 characters.' It also implies valid input types and length constraints, so the agent can construct the query correctly without further schema documentation.

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 uses a specific verb ('Find') and explicitly lists the four resource types (members of Congress, tickers, 13F funds, Fed officials), plus the concrete outputs (politician id, fund id, exact symbol). This clearly distinguishes it from the sibling tools that consume those IDs rather than performing lookup.

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?

'Use this first when you have a name or part of a ticker and need the politician id, fund id or exact symbol that the other tools take' is explicit guidance on when to invoke this tool before others. It also frames the tool as a lookup/disambiguation step within the broader toolset.

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, idempotentHint and closed-world, so the safety profile is covered; the description goes beyond that by explaining what the numbers mean (excess return in percentage points over the same trading days as SPY) and warning that results are regime-scoped and can be thin. It never says what happens with an invalid/nonexistent score_version, which keeps it from a 5.

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 payload is front-loaded into the first sentence and the supporting detail follows in a logical order (what is snapshotted → what is returned → how to read it → regime caveat → args). It runs longer than strictly necessary and re-explains the SPY logic twice, so a sentence or two could be trimmed.

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 needn't enumerate return fields, and it instead supplies the interpretive context an agent needs: the 30/60/90-day horizon, SPY-relative framing, sample-size caveat, and version scoping. The only remaining gap is not stating what an out-of-range or unknown score_version yields.

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% and the schema only offers a nullable integer with default null, so the description has to carry the meaning — and it does: the parameter restricts to one scoring regime and defaults to the current one. The only weakness is a mild mismatch with the schema's literal null default, leaving an agent to infer that null means 'current regime'.

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?

Opens with a concrete verb+resource question ('Does a label actually go up — and beat the market?') and then states exactly the artifact: per-label score-bucket outcomes at 30/60/90 days with resolved counts, up/down/flat, win rate, and excess return vs SPY. That is specific enough to separate it from siblings like ticker_signal, top_signals, or leaderboard, which do not report resolved forward returns.

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?

Gives explicit consumption guidance ('lead with the SPY numbers') and a reporting rule ('Small resolved counts mean the regime is young — say so'), plus the caveat that scoring regimes change over time. It does not name a sibling tool or state when to prefer one over the other, so it stops 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.

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.