Congress Trade Alerts

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

No annotations are provided, so the description carries the full disclosure burden. It does disclose the scope and granularity of what is computed (including the "since records began + 30/60/90d" windows), but says nothing about cost, freshness of data, or result size — low risk given zero parameters, yet not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that packs the full metric list with no filler. It is dense but readable; the parenthetical shorthand ("since records began + 30/60/90d") and the unexplained acronym "CTA" cost it a bit of 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 zero-parameter, read-only aggregate with no output schema, the description supplies the one thing an agent needs: what the response contains. Only the absence of any note on data currency or expected response shape keeps 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?

The tool takes no parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; the description cannot be faulted for missing parameter meaning when the schema is empty.

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?

Uses a specific verb ("Get") with a concrete resource ("high-level stats on records") and enumerates the metrics returned: trade counts across time windows, member coverage, average filing delay, and sector breakdown. That enumeration differentiates it from single-dimension siblings such as get_chamber_breakdown, get_party_breakdown, and get_top_tickers, though it never names those siblings directly.

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?

"High-level stats" implies a summary/overview use case, but there is no explicit statement of when to choose this over the breakdown tools or what question it answers. An agent must infer that this is the entry-point overview tool before drilling into the more specific 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?

With no annotations, the description carries the full behavioral burden, and it does disclose a meaningful data-quality caveat: Senate counts since October 23, 2026 are partial. However, it defers detail to external 'server instructions' and says nothing about how counts are derived (trades vs filings), duplicate handling, or the shape of the returned breakdown.

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?

Two sentences, zero filler, and the core capability is front-loaded before the caveat. Each sentence earns its place: one defines the output, the other flags a correctness risk.

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-optional-parameter count tool with no output schema, the description covers what is returned (counts split House/Senate) and the main caveat. The one gap is that it offloads the partial-data explanation to external server instructions rather than stating the effect on the numbers here.

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 'days' parameter already documents the look-back window and the 45-day disclosure lag. The description reinforces this by calling it an optional date filter, so the agent understands omitting it means no window, adding a small amount of meaning 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 uses a specific verb+resource, 'Get counts of the trades ... broken down by chamber (House vs Senate)', so the agent knows exactly what aggregate it returns. The chamber facet implicitly separates it from get_party_breakdown, but no sibling is named explicitly, so it stops short of full 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?

Usage is only implied: an agent infers this is the tool for chamber-level aggregates and the 'optional date filter' phrasing hints at an unfiltered all-time default. There is no explicit when-to-use versus get_party_breakdown/get_aggregate_stats guidance and no stated prerequisites 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?

With no annotations, the description must carry the full behavioral burden. 'Returns' and 'CTA's records' imply a read-only lookup over a dataset, and the output contents are described well. However, it does not disclose that the newest part of the window may be incomplete due to disclosure lag (that caveat lives only in the 'days' schema field), nor anything about data freshness or scope limits of CTA's records.

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?

A single dense sentence that front-loads the scope ('For a given congressional committee') before enumerating return values. Nothing is redundant, though the sentence is long enough that the enumerated outputs could be easier to scan as a short list.

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?

No output schema exists, and the description compensates by naming the returned fields (members, trade counts, percentage of committee). For a two-parameter read tool this is nearly sufficient; the main omission is any note on data completeness or how partial committee-name matches resolve.

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 both parameters are already documented, including the 45-day disclosure lag and default of 90 days. The description only restates 'last N days' and 'given congressional committee' without adding format, matching behavior, or partial-match semantics beyond what the schema provides. Baseline 3 applies.

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 and resource ('returns which members have stock trades... for a given congressional committee') and spells out the three outputs: member list, trade counts, and committee participation percentage. It does not name any sibling to distinguish itself from, but the committee-level aggregation scope makes it separable from get_member_trades and get_trade_feed on inspection.

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?

Usage is implied by 'for a given congressional committee', which signals the committee-aggregate use case, but there is no explicit when-to-use or when-to-prefer-a-sibling statement (e.g. versus get_member_trades for an individual, or get_aggregate_stats for cross-committee figures). The agent must infer placement from the sibling list.

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

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

With no annotations present, the description carries the full burden and does so well: it discloses a silent failure mode (a non-matching name returns total_trades 0 with no error) and a scope limitation (only trades filed under that exact spelling are counted). These are exactly the non-obvious behaviors an agent would otherwise misread as "this member made zero trades."

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?

Three dense sentences with no filler, and the field list is front-loaded before the invocation caveats. The final sentence restates the exact-spelling constraint already covered earlier, which is mild redundancy but arguably reinforces the key failure condition.

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?

There is no output schema, and the description compensates by enumerating the returned fields, so an agent knows what it gets back without a schema. Combined with the failure-mode disclosure and the name-resolution step, nothing needed to call this 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 coverage is already 100%, so the baseline would be a 3, but the description adds material meaning beyond the schema: the name is the STOCK Act filer name with honorifics stripped and is often a legal name rather than a common name, and a mismatch fails silently. That transforms a plain string parameter into one with known gotchas.

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 specific verb and resource ("Returns a trading profile for one member of Congress") and enumerates the exact fields returned — trade count, buys/sells, first/last trade dates, average disclosure lag, party, chamber, state, committees. This clearly separates a summary profile from the per-trade listings a sibling like get_member_trades would give, though it never names that sibling explicitly.

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 a concrete prerequisite workflow — resolve the name with search_members_and_tickers before calling — and explains the consequence of skipping it. It stops short of stating when to prefer this over get_member_trades or get_committee_trading, so the routing guidance is contextual rather than exhaustive.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the silent-failure mode ("A name that does not match returns count 0 and no error"), the name-normalization rule (honorifics stripped, often a legal name), and the single-spelling limitation. It does not cover auth requirements, rate limits, or what happens at the limit boundary, so it falls short of full behavioral disclosure.

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?

Three sentences, all front-loaded: capability and ordering first, then the critical name-matching constraint, then the escape hatch to the sibling. Every clause carries operational information an agent needs, and none restates the name or title.

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?

There is no output schema, yet the description never describes the shape of a returned trade record (fields, count semantics beyond the failure case), leaving the agent to infer it. Everything else an agent needs to call the tool correctly — name resolution, filtering, ordering, empty-result behavior — is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters, and the baseline is 3. The description adds real meaning for member_name by explaining how the stored spelling is derived and why an exact match matters, but adds nothing new for days, limit, or ticker beyond what the schema states.

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 and resource ("Returns stock trades disclosed by one member of Congress"), plus ordering (newest first) and the optional filters. It also distinguishes itself from the two siblings an agent would most likely confuse it with, search_members_and_tickers and get_trade_feed.

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 preconditions ("resolve a common or partial name with search_members_and_tickers first") and an explicit alternative for the edge case where a member filed under multiple spellings ("use get_trade_feed with a partial name"). When-to-use and when-to-use-something-else are both spelled out.

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?

No annotations are supplied, so the description carries the full behavioral burden. "Get" implies a read, but nothing is said about whether counts are of trades or distinct filers, whether a total is included, or how the data-refresh lag affects the numbers — the lag caveat lives only in 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?

A single front-loaded sentence with no filler. It is efficient, though the brevity is also the source of the missing usage and behavioral detail.

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 one-optional-parameter aggregation tool with no output schema, the definition should sketch the return shape (per-party counts, presence of a total) and the default window. It gestures at the output with "counts" but leaves the agent guessing on both points.

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%, and the days parameter is documented with range limits and an explicit note that recent windows are incomplete. The description adds only "optional date filter," which restates rather than extends the schema, so baseline 3 applies.

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 and resource ("get counts of the trades") plus the exact breakdown dimension ("by party (D/R/I)"), which cleanly separates it from get_chamber_breakdown and get_aggregate_stats by implication. It stops short of naming those siblings explicitly, so it lands just below the top mark.

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 only usage signal is "with optional date filter," which implies an all-time default when days is omitted. There is no statement of when to prefer this over get_chamber_breakdown or get_aggregate_stats, and no prerequisites 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?

With no annotations, the description carries the full behavioral burden, and it does disclose two meaningful traits: results are restricted to purchases (sells excluded) and are rolled up per politician rather than per trade. It says nothing about ordering, result limits, pagination, or whether the window honors trade date versus disclosure date beyond the schema's own note.

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?

It is a single dense sentence with no wasted clauses, and the key qualifiers (recorded purchase, CTA's records, last N days, aggregated per politician) are front-loaded. The one long sentence is slightly hard to parse but nothing is redundant.

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 lookup with complete schema coverage this is close to adequate, and 'aggregated per politician' hints at the return shape. However, with no output schema the description should say what each aggregated record contains (count, value, dates), which it does not.

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%, and the schema already explains the days window, its 1-365 bounds, the 90 default, and the 45-day disclosure lag. The description's 'last N days' adds nothing beyond that, so the 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 gives a specific verb ('Get'), a precise resource ('members of Congress with a recorded purchase of a specific ticker'), and a stated output shape ('aggregated per politician'). The aggregation note implicitly separates it from trade-level siblings like get_trades_by_ticker, but no sibling is named explicitly.

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?

Usage is only implied: an agent can infer you call this when you want buyers of one ticker rather than a raw trade list. There is no explicit when-to-use, when-not-to-use, or named alternative among the eleven siblings, so the agent must infer routing from the purpose sentence alone.

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

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

With no annotations supplied, the description carries the full behavioral burden. It discloses the important default that omitting tx_type ranks purchases and sales together rather than excluding one side, which is real value. But it says nothing about the return shape (ranked tickers with accompanying counts?), whether results are paginated, or that this is a read-only aggregation, leaving meaningful disclosure gaps for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core operation, followed by the routing rule for tx_type. Every sentence carries information and nothing is redundant 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 simple three-parameter read tool this covers the mechanics adequately, but with no annotations and no output schema the description should do more to describe what comes back (a ranked list, with counts, limited by 'limit'). An agent knows how to call it but not exactly what it will receive.

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 already 100%, so the baseline is 3. The description still adds meaning beyond the schema by clarifying that the omitted-tx_type case ranks buys and sells together — the schema only says 'Omit for all trades,' which is ambiguous — and by framing tx_type as selecting the most-bought vs most-sold ranking rather than a mere filter.

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 and resource: ranking tickers by count of congressional trades within a look-back window, with the CTA record scope named. The only gap is that it never contrasts itself with nearby siblings like get_top_traders or get_trades_by_ticker, so an agent must infer this is the aggregate-ranked view rather than the per-trade list.

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 clear guidance for choosing among the tx_type values (Purchase for most-bought, Sale for most-sold, omit for combined), which is genuinely useful. However, that is parameter-level guidance, not tool-level guidance: nothing says when to pick get_top_tickers over get_top_traders or get_trades_by_ticker, and no prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full burden; 'Returns' signals a read-only, side-effect-free operation and 'in CTA's records' scopes the data source. It does not disclose the important caveat that recent windows are incomplete due to disclosure lag (that detail lives only in the schema), nor the return shape or tie-breaking 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?

A single tightly packed sentence that front-loads the resource and ranking basis before the optional filters. Every clause carries meaning and there is 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?

For a three-parameter, no-annotation, no-output-schema tool, the agent still cannot tell what each returned trader entry contains (name, party, chamber, count?) or how ranking ties and short result sets are handled. Adequate to know what to call, thin on what comes back.

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% and the parameter docs are unusually rich, including the 45-day disclosure-lag warning. The description only echoes chamber and date-window filtering without adding syntax, defaults, or interaction details, so the schema does the heavy lifting.

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 and resource ('Returns the members of Congress with the most trades') plus the ranking basis ('by trade count'), which is enough to separate it from get_top_tickers or get_member_trades by resource alone. It never names an alternative explicitly, 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?

The one-sentence scope implies when the tool fits (ranking members by volume), but there is no explicit when-to-use or when-not guidance against siblings like get_member_trades, get_party_breakdown, or get_aggregate_stats. The clause about chamber and date window is a restatement of parameters rather than selection guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the data source (CTA records) and that results are 'recently disclosed,' which is some context, but it never states ordering, how fresh 'recent' is, whether the call is read-only, or what the response looks like.

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?

A single sentence that front-loads the resource and then the filter list. There is no filler or redundancy.

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 definition is minimally complete: six parameters, no output schema, and no annotations. It explains what the tool fetches and what can be filtered, but leaves out return format, default ordering, and the recency window, which an agent would need to use it confidently alongside the many sibling trade tools.

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 every parameter is already documented, including the politician partial-match example. The description only enumerates the filters at a high level and adds no syntax or format detail beyond the schema, which is the expected 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 gives a specific verb and resource — 'Get recently disclosed congressional stock trades from CTA's records' — and names the five filter dimensions. It is clear what the tool returns, but it does not distinguish itself from overlapping siblings such as get_member_trades or get_trades_by_ticker.

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 phrase 'with optional filters' implies the tool is a general browsing endpoint, but there is no explicit guidance on when to choose it over get_member_trades, get_trades_by_ticker, or get_committee_trading. Usage is inferable but not stated.

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

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

With no annotations, the description carries the whole behavioral burden, and it does disclose two useful traits: data comes from CTA's records and results are ordered newest first. It does not disclose pagination behavior, the default cap of 50, how filing lag affects totals, or what a returned trade record contains.

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?

One sentence, front-loaded with the verb and resource, ending on the useful ordering detail. There is no filler and nothing an agent must read past to reach the core claim.

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 three-parameter read tool this covers the essentials, and the rich parameter schema compensates for the lack of annotations. But with no output schema, the description never indicates what a trade record looks like (member, party, chamber, amount, filed date), which an agent would need to plan follow-up calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains the ticker format, the days look-back window with the 45-day disclosure lag caveat, and the limit cap. The description adds nothing beyond 'specific stock ticker symbol', so the baseline 3 applies.

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 gives a specific verb ('Get') plus resource ('congressional trades') and scope ('for a specific stock ticker symbol'), and it adds ordering ('newest first'). That distinguishes it from a member-centric sibling such as get_member_trades, though it never names the siblings it competes with.

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?

Usage is only implied: an agent can infer this is the right tool when it has a ticker symbol and wants trades. There is no explicit when-not guidance, no mention of alternatives like get_ticker_buyers or get_trade_feed, and no note on prerequisites or data-source limits.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses case-insensitivity, per-entity result caps, trade-count ordering, and the important aggregation behavior where multiple spellings collapse into one row with summed trade_count, which can make downstream get_member_trades return fewer trades. It does not mention read-only safety, rate limits, or the exact fields returned, so it falls short of exhaustive.

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 capability is front-loaded in the first sentence, followed by result semantics, then the intended use case, then the known caveat. Every sentence contributes a distinct fact with no filler, despite the description being fairly dense.

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 lookup with no annotations and no output schema, the description covers what is matched, how results are capped and ordered, and the key aggregation pitfall. It could add a sentence on the returned fields (e.g., whether ticker and member results are in separate lists) but the essential call-time information is present.

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 the schema already documents both parameters and a baseline of 3 applies. The description goes beyond it by clarifying that limit applies independently to members and to tickers (up to limit of each), which changes how an agent sizes the value.

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 specific verb and resource set: case-insensitive substring search over member names, ticker symbols, and company names. It also explains its role relative to siblings, positioning itself as the resolver that feeds get_member_trades and get_member_profile, so an agent can distinguish it from the lookup tools without comparing schemas.

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 routing rule: use this to turn a common or partial name into the exact stored name that get_member_trades and get_member_profile require. It also states a clear boundary condition, that matching is substring-only with no misspelling correction, which tells the agent when this tool will fail and another approach is needed.

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