HillSignal

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

The readOnlyHint annotation already signals safety, and the description adds meaningful behavioral context: it aggregates every matching award and returns totals rather than a page of records. It also discloses that filters are shared with search_awards, giving the agent useful expectations about match semantics.

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 carry all essential information: grouping dimensions, computed metrics, usage example, and the distinction from paginated search. Nothing is redundant and the key behavior is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an aggregation tool with no output schema, the description compensates by listing the computed fields and grouping options. It could be more explicit about result ordering, the meaning of 'share,' or the cap on returned groups, but the combination of title, schema, and description is adequate for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters. The description adds a light semantic link by saying filters match search_awards, but it does not meaningfully deepen understanding of individual parameter formats or edge cases 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 ('Aggregate') and names the exact resources and grouping dimensions: recipient, resolved ticker, or awarding agency. It also lists the output metrics (count, dollars, share, first/last, largest) and distinguishes itself from search_awards by clarifying it counts all matches rather than returning a page.

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 a concrete query example ('who won the most from the Navy this year') and explicitly notes this tool counts all matches, not a page, which signals when to choose it over a record-returning tool like search_awards. It does not explicitly name when-not-to-use or fully contrast with sibling aggregation tools like pac_totals.

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 readOnlyHint already present, the description adds helpful behavioral context by stating that the result is one row per transaction and includes the disclosed amount range and filing PDF. This is useful beyond the annotation because it tells the agent what kind of output and data shape to expect.

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 with the core purpose, then lists query dimensions and the return shape in two efficient sentences. There is no fluff or unnecessary 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 simple read-only query tool with five optional parameters and no output schema, the description sufficiently covers the data source, available filters, and primary output fields. Some minor details like ordering, exact ticker matching, or empty-result behavior are absent, but they are not critical given the schema coverage.

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

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

All five parameters are individually documented in the schema, so the baseline is 3. The description adds a coherent framing of the filters ('by member name, ticker, transaction type or date') but does not materially enrich parameter semantics 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 clearly identifies the tool as returning congressional stock trades from House and Senate Periodic Transaction Reports, and lists the main query dimensions: member name, ticker, transaction type, and date. It is specific enough to be understood, though it does not explicitly differentiate itself from siblings like insider_trades.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when this tool is appropriate: querying disclosed congressional stock trades by several useful filters. It does not explicitly name alternatives or exclusion criteria, but the domain is well-scoped by 'members of Congress' and the filter 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?

The annotations already declare readOnlyHint=true and idempotentHint=true; the description is consistent with them and adds a meaningful behavioral guarantee: the tool reports row counts and latest row dates, so it gives freshness and coverage signals in one call. 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?

Two sentences, front-loaded with the concrete substance (row counts, latest dated row, coverage) and then a crisp call-condition sentence. No filler; every clause earns its place.

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 zero parameters and no output schema, the description supplies exactly what an agent needs to decide whether this tool answers a completeness question: what it returns, for which datasets, and when to call it. It does not need to restate annotations.

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?

Zero parameters, so there is nothing to disambiguate and no way to mis-invoke. The description clarifies what the output will cover (every dataset, entity-resolution coverage), which matters more than parameter docs here.

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 title 'What HillSignal has' and description 'Row counts and the latest dated row for every dataset behind these tools, plus entity-resolution coverage' make the purpose concrete: this is an introspective coverage-reporting tool. It distinguishes itself from siblings that answer domain questions because it reports on dataset completeness rather than the underlying data itself.

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 explicitly gives call conditions: 'Call it when an answer depends on how complete the data is, or before saying something does not exist.' This is exactly the kind of when-to-use guidance that beats the baseline; it also implicitly marks when not to call it (when you need the underlying content itself).

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 readOnlyHint annotation already communicates that this is a read-only operation, so the description does not need to restate safety. The description adds context about the content returned (affected sectors and tickers), but it does not disclose any other behavioral traits such as sorting, pagination, or query semantics. No contradiction with annotations 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 a single concise sentence that front-loads the core resource and immediately specifies the distinguishing output fields. There is 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?

For a simple read-only listing tool with four optional, fully documented parameters, the description is mostly complete. It says what the tool returns and the readOnly annotation covers safety. It could mention ordering or that it returns recent items, but this is not essential given the schema and annotation coverage.

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

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

Schema description coverage is 100%, so the parameters are already fully documented. The description adds no parameter-specific meaning beyond the schema, which is acceptable given the high coverage 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 clearly identifies the resource: executive orders, proclamations, and memoranda, and mentions the key output dimensions (affected sectors and tickers). It lacks an explicit verb such as 'search' or 'list,' but the intent is evident and it is distinct from all sibling tools.

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?

No guidance is given about when to use this tool versus alternatives, such as search_bills or search_awards. The description relies entirely on the tool name and sibling list for context, with no explicit usage conditions 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?

The readOnlyHint annotation already establishes that this is a safe read operation, and the description adds the meaningful behavioral scope of returning only $5M+ Form D placements. However, it does not disclose details like default limit behavior, result ordering, or whether filters are combined with AND/OR logic.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently communicates the core resource, the threshold, and the available filtering dimensions in a scan-friendly way.

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, five-parameter query tool, the description covers the resource and filter dimensions but leaves notable gaps: there is no output schema, so the return shape is unstated, and the description does not clarify how multiple filters interact or what a result row contains. This is adequate but not 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 100%, so the schema fully documents all five parameters. The description adds modest semantic context by framing the tool around $5M+ private placements and mentioning issuer name, ticker, date, and minimum amount, but it does not add meaning beyond the schema's parameter descriptions.

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 (SEC Form D private placements) and the key scope ($5M and up), and it names the main query dimensions. It lacks an explicit verb such as 'list' or 'search', so it reads more like a dataset description than an action, which prevents a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool can be filtered by issuer name, ticker, date, or amount, but it gives no guidance on when to choose this tool over sibling tools such as outside_money, institutional_holders, or money_trail. There are no exclusions, alternatives, or contextual signals to help an agent decide.

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 already declare readOnlyHint=true, so safety is covered. The description adds useful behavioral details: the lookup is for a single company in the federal record and name resolution is exact. It does not mention not-found behavior, rate limits, or auth, but with read-only coverage this is acceptable.

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 sentences with no filler. The data categories are front-loaded, and the lookup methods follow immediately. Every clause adds information that helps an agent select and invoke the tool.

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 company profile lookup, the description covers the essential context: scope (one company in the federal record), return contents, and available identifiers. It doesn't specify an output schema or edge cases like missing parameters, but the enumerated data categories and exact-match note are sufficient for initial tool selection.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists the same three parameters (ticker, entity_id, name) and adds no semantics beyond the schema, except reinforcing the exact-match behavior for name, which is already in the schema description.

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 a single-company lookup tool: 'One company in the federal record' and enumerates the data categories returned (contracts, PACs, patents, private raises, board seats, insider trades, connections graph). It also states the lookup keys (ticker, entity_id, name), making the tool's purpose 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 gives clear invocation guidance: 'Look up by ticker, entity_id, or a name (resolved exactly).' It implies this tool is for retrieving one company's full profile and does not need exclusions or alternatives because no sibling tools are in context. It lacks an explicit when-not-to-use statement, but the context is clear.

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

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

The readOnlyHint annotation already signals a safe read operation, so the bar for additional behavioral disclosure is lower. The description adds useful behavior details: it resolves tickers in financial disclosures, includes recent stock trades, and returns candidate options for ambiguous names. However, it doesn't mention what happens if no match is found, rate limits, or whether the returned profile includes all listed sections at once.

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 sentences, front-loaded with the primary purpose and key data categories, then the lookup mechanics and ambiguity behavior. Every clause earns its place, and there is no fluff or repetition of the schema 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?

Given the tool has no output schema and only two parameters, the description covers the main data contents and lookup behavior well. It could mention what happens on no match or how to disambiguate (e.g., additional fields returned), but for a read-only profile lookup with a simple interface, the description is reasonably 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 100% — both 'name' and 'bioguide_id' are described in the schema. The description adds the relationship between the two parameters: they are alternative lookup keys, and ambiguous names yield candidates. But the schema already covers the syntax and examples, so the description only adds marginal semantic value beyond the structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific purpose: retrieving a member of Congress profile with committees, board seats, stock trades, and PAC contributors. It clearly distinguishes the lookup methods (name or bioguide_id) and mentions that ambiguous names return candidates, which sets expectations beyond a simple profile fetch.

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 need a member's committees, financial disclosures, recent trades, or top PAC contributors. It doesn't explicitly name alternatives or state when not to use it, but the specificity of the data fields and the sibling tool context (award_totals, search_calls, etc.) make the use case fairly 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 provide readOnlyHint=true, covering the safety profile. The description adds useful behavioral context about what the tool returns, especially valuable because there is no output schema: a dated chronology with beats linked to source records, significance, watch-outs, and evidence. It does not discuss auth or rate limits, but those are less critical for a simple read-only lookup.

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 uses a colon to organize five distinct output components with no filler or repetition. Every phrase carries informational weight, making it easy for an agent to quickly understand what the tool provides.

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 tool with one parameter and no output schema, the description adequately communicates the main return components and single-theme scope. It could have explicitly referenced list_themes as the source of theme_id, but that relationship is already documented in the input schema, so the overall definition is sufficiently 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 input schema covers theme_id fully, including the note that it comes from list_themes and may optionally include the hs:theme: prefix. The description itself adds no parameter-level meaning, so it does not exceed the baseline set by the schema's 100% parameter coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ('one theme'), implies the retrieval operation through 'in full', and specifies the returned contents: setup, dated chronology with source-record links, importance, watch-items, and evidence. It clearly suggests the distinction from list_themes by emphasizing a single theme, though it does not name a sibling or use an explicit verb.

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 use when needing a complete chronology for one theme rather than a list of themes or other entity-specific details. However, it never explicitly states when to choose this tool over list_themes or other siblings, nor does it give any 'not for' 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?

The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds modest context by naming SEC Form 4 as the data source and listing filter dimensions, but it does not disclose defaults, pagination, or what the returned rows contain.

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

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

The description is a single compact sentence that front-loads the core resource and then lists the relevant filters. There is no filler or redundant wording.

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 read-only lookup with no required parameters and full schema coverage, the description covers the main query keys and filter options. It does not state what happens when no ticker or insider is provided or describe the return schema, but the missing details are not critical for invoking the tool correctly.

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

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

Schema description coverage is 100%, so all six parameters are already documented. The description roughly restates ticker, insider, type, min_value, and since but adds no deeper semantics beyond the schema; limit is not mentioned.

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 SEC Form 4 insider transactions as the resource and specifies lookup keys (ticker, insider name) and filters. It differentiates from siblings only implicitly through 'Form 4' and 'insider,' rather than explicitly naming alternatives.

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 a direct query/filter use case, which is helpful, but it does not explain when to prefer this tool over related siblings like congressional_trades, form_d_raises, or institutional_holders. No exclusions or alternative routing are provided.

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 annotation, the description discloses that only filings ingested by HillSignal are included, that results are the largest holders sorted by position, and that each institution is represented by its latest position. This adds meaningful behavioral context about data scope and deduplication.

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?

Single sentence with no filler, front-loaded with the core resource, and every phrase adds scope or behavior.

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 read-only list tool with two well-documented parameters, the description states the source, ordering principle, and deduplication behavior. No critical invocation information appears 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?

Input schema already documents both parameters at 100% coverage, so baseline is 3. The description adds context about 'largest' and 'latest position' but does not add parameter-level detail 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 identifies the resource ('largest institutional holders of a ticker') and the filing source (13F-HR), making the tool's purpose recognizable. It lacks an explicit action verb such as 'list' or 'get,' and it does not explicitly contrast with sibling tools, but the noun phrase is specific enough.

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 the tool — when a user wants institutional ownership from 13F filings — but it does not provide explicit guidance or alternatives. It does not say when to prefer insider_trades, congressional_trades, or other sibling 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?

The readOnlyHint annotation already covers safety, and the description adds useful context about cross-source scope and provenance. It does not describe pagination, sorting details, or response shape, but for a read-only feed the added context is adequate.

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 concise, front-loaded sentences cover the tool's scope, provenance, and optional filters with no filler. Every sentence contributes useful information.

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 tool with four optional, fully documented parameters and no required inputs, the description plus schema is mostly complete. It could be stronger with explicit return-format context, but the absence of an output schema makes this a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description only restates the filter options at a high level without adding meaning beyond the schema property names.

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 newest events across all sources, listing example categories and mentioning optional filters. It is distinguishable from source-specific siblings like congressional_trades or executive_orders, though it does not explicitly name an alternative.

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: the phrase 'newest events across every source' suggests this is the broad firehose tool, and the optional filters hint at narrowing results. However, there is no explicit guidance about when to prefer a specialized sibling tool or when not to use this one.

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 readOnlyHint annotation already declares the operation safe, and the description adds useful behavioral context: the themes are currently funded, come from multiple source types, and each result includes a permanent page and verdict. However, it does not disclose whether the list is paginated, ordered, or limited in any way, which is relevant for a list operation.

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

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

The description is a single dense sentence with no filler; every clause contributes meaning about scope, source types, or result attributes. It loses one point because it is phrased as a noun phrase rather than a clear action statement, which slightly reduces immediate readability.

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 tool with no output schema, this description provides the core semantics an agent needs: the domain (government themes), currency ('currently funding'), sources, and what each result contains (permanent page and verdict). It would be more complete if it mentioned whether all themes are returned at once or if pagination/limits apply, but the current level is adequate for 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 tool has zero parameters, so schema coverage is trivially 100%. The description's scope statement ('currently funding') reinforces that this is an unfiltered, global list. No parameter-level documentation is needed, so a baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource: government themes currently being funded, across bills, contracts, solicitations, and filings, and notes each theme has a permanent page and a verdict. It lacks an explicit imperative like 'Lists', but the tool name plus description makes the operation unambiguous. It does not explicitly contrast with get_theme, though the plural framing implies a list operation.

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?

No guidance is given on when to use this tool versus siblings such as get_theme, search_bills, or search_opportunities. An agent must infer that list_themes is the broad overview tool and that get_theme is for a specific theme. The absence of any when-to-use or when-not-to-use guidance leaves a clear gap.

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

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

The description goes well beyond the readOnlyHint annotation by disclosing identity resolution behavior, employer-spelling folding, FEC name handling, ambiguous-name behavior, and the exact components of the returned trail. This gives the agent important expectations about edge cases and return semantics that annotations alone 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?

The description is dense but every sentence contributes: it defines the question being answered, outlines the return structure, and resolves the most likely input ambiguities. The most important scoping information is front-loaded in the first sentence.

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?

Even without an output schema, the description enumerates the main return categories, explains how names are resolved, and mentions the employer narrowing mechanism. For a tool of this complexity, this is sufficient for an agent to select it and invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is already solid. The description adds valuable semantic detail for the name parameter, explaining that names can be written naturally, that FEC form is handled, and that ambiguous names expose matched_as and can be narrowed with employer. This meaningfully augments the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and action: following one donor's money from initial giving through intermediate entities to recipient committees and their spending. It also distinguishes itself from siblings by focusing on a donor-centric trail rather than aggregate totals or politician-centric lookups. Example questions like 'how much did Elon Musk give to Trump' make the intended use immediately recognizable.

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 clearly conveys when to use the tool via concrete question patterns and by defining the scope as 'a person or organization.' It does not explicitly name sibling tools or state when not to use it, but the context is strong enough that an agent can infer the appropriate 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 provide readOnlyHint=true, and the description adds meaningful behavioral context beyond that: the data source (FEC Schedule E), the scope (independent spending to support or oppose), and that it returns totals. It does not mention pagination, response shape, or rate limits, but for a read-only data lookup with strong source disclosure, this is solid.

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 first sentence defines the tool precisely, the second provides illustrative queries, and the final tip is short and useful. Every sentence earns its place with no redundant wording.

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 tool's simplicity, three well-documented parameters, and no output schema, the description covers the essential context: what counts as outside money, what is returned, and example natural-language queries. It omits details like whether support and opposition totals are shown separately, but the phrase 'support or oppose' and the limit parameter's 'per side' description cover the main gaps.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds a modest reminder that candidate names go in as written, which complements the schema examples. It does not add substantive meaning to the cycle or limit parameters beyond their existing schema descriptions, so no higher score is warranted.

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 with a clear resource: it lists every super PAC and other filer spending independently to support or oppose a candidate, with totals from FEC Schedule E. It is unambiguously per-candidate and independent-spending oriented, which distinguishes it from sibling tools like pac_totals or super_pacs. The example queries reinforce what the tool answers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context through example questions such as 'who is backing Trump' and 'which groups are attacking this senator', implying when to use the tool. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5. The note 'Candidate names go in as written' also gives practical input 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?

Annotations only declare readOnlyHint, so the description adds useful behavioral context: lookup can be by public-company ticker or partial committee name, and results include the candidates funded. It does not cover edge cases like both filters combined or default limit, but the read-only safety is already annotated.

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 front-load the core function, then give illustrative queries and routing to alternatives. No redundant filler; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no required parameters, the description covers purpose, lookup modes, result content, and alternatives. It is slightly incomplete about whether at least one filter is required and how ticker and committee_name interact if both are supplied, but overall an agent has enough to invoke it sensibly.

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?

Input schema descriptions cover all three parameters (limit, ticker, committee_name), so baseline is 3. The description reinforces the ticker/committee_name lookup roles with examples but adds no meaning beyond the schema and does not clarify parameter interaction.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact resource: corporate and trade-association PACs linked to a public company or found by committee name, with the candidates they fund. It uses concrete example questions to make the lookup intent unmistakable and explicitly distinguishes itself from super_pacs and money_trail.

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 states when to use it: for corporate/trade-association PACs by ticker or committee name. It also gives a clear exclusion and alternative: for super PACs and mega-donors, use super_pacs and money_trail instead. This is explicit routing 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?

The readOnlyHint annotation already signals a safe read operation, so the description doesn't need to re-establish that. It adds useful behavioral context: contributions are FEC Schedule A based, conduits like ActBlue and WinRed are separated out, and mode changes the interpretation from contributor totals to committee-reported disbursements. No contradiction with annotations 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?

Three sentences carry all the essential information: scope, data source, mode behavior, and routing to super_pacs. There is no filler, no repetition of schema details, and the most decision-relevant facts are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with no required parameters and a fully self-documented schema, the description covers everything an agent needs to invoke it correctly: ranking basis, election-cycle dimension, conduit handling, mode switch, and the boundary with super_pacs. The return shape is sufficiently implied by 'ranked by total dollars,' and no output schema exists to add further detail.

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 baseline is 3. The description adds real value beyond the schema by explaining what mode=disbursers actually does and by framing cycle as an election-cycle filter. limit and query are already well described in the schema, so they don't need additional 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 what the tool does: it lists PAC contributors to tracked candidates ranked by total dollars from FEC Schedule A. It also explicitly differentiates the tool from super_pacs, so an agent can distinguish it from the most similar sibling 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?

It gives explicit usage direction: use for 'which PACs donate the most to Congress' questions, and use super_pacs instead for super PAC questions. It also explains when mode=disbursers should be selected, making the routing guidance actionable.

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 only declare readOnlyHint and idempotentHint, which are a safety profile, not behavior. The description adds substantial behavior beyond that: the normalization strategy, the underlying data sources (SEC legal names, aliases, Exhibit 21 subsidiary map), and the return contract (method + confidence, or the miss reason). The 'never guesses' guarantee is a meaningful behavioral disclosure about failure modes.

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 with zero waste: purpose is front-loaded, the entity-type enumeration justifies itself by scoping valid inputs, and 'Never guesses.' is a compact behavioral qualifier. Every sentence earns its place.

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 tool with no output schema, the description covers the input domain, the matching strategy, and the return values (method and confidence, or the reason for a miss). Paired with the read-only/idempotent annotations, nothing an agent needs to invoke it 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 100% ('Organization name as written'), so the baseline is 3. The description adds material meaning to the `name` parameter by enumerating what kinds of organization names are valid inputs and clarifying that the name will be matched via exact normalized comparison.

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 ('Map'/'Resolve') and resource (organization name → public-company ticker), with an enumerated scope of accepted entity types (contract recipient, subsidiary, PAC sponsor, Form D issuer). The exact-match and 'never guesses' qualifiers distinguish it from the sibling search/PAC tools even though 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?

The usage context is implied by the exact-normalized-match behavior and the 'never guesses' guarantee, which signals this is not the tool for fuzzy resolution. However, it never names a sibling alternative or states explicit when-to-use/when-not-to-use conditions; an agent must infer when to prefer this tool over the other lookup/search 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?

With only readOnlyHint in annotations, the description does the heavy lifting. It discloses the data source, $10M+ threshold, pagination behavior (up to 50 per call), total_matching, and sort options. This goes well beyond the annotation without contradicting it.

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, purposeful sentences: what it searches, what it returns, and when to use the sibling instead. No filler, and the core scope is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with no output schema, the description covers the essential behavior: filters, source, threshold, pagination, sorting, and sibling routing. A slightly more explicit statement of the returned record fields would make it fully complete, but it is already sufficient for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the parameters are already documented. The description adds useful context like the $10M+ floor and pagination style, but it doesn't explain individual parameter semantics beyond what the schema provides. Baseline 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 uses a specific verb ('Search') with a clear resource ('federal contract awards') and scope constraints (USAspending, $10M+). It also distinguishes itself from award_totals by naming it, making the tool's purpose 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 explicitly says to use award_totals for 'who won the most' questions, providing a clear alternative and the condition that selects it. This gives the agent actionable routing guidance rather than leaving it to infer when to use which tool.

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

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

Annotations already provide readOnlyHint=true, and the description does not contradict that. It adds the useful context that results include analysed sector and ticker exposure, but it does not disclose pagination, result formatting, or any other behavioral details beyond what the annotation already signals.

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 leads with the core scope and then lists the available filters. Every word earns its place, with no redundant filler or repetition of schema details.

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, all-optional search tool, the description plus the fully-covered input schema gives an agent enough to select and invoke it: the search scope, the key filters, and the nature of the results. It is slightly incomplete on alternative routing and no output schema, but those are secondary 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 description coverage is 100%, so the baseline is 3. The description restates the main filter dimensions (bill number, ticker, sector, date, event type) but adds no extra semantic detail beyond what the parameter descriptions already provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool does full-text search over bills, contract awards, and other government events, with analysed sector and ticker exposure. This gives a specific verb and resource, though it does not explicitly differentiate itself from search_awards or latest_events among the siblings.

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 intended use is implied: an agent should use this when searching bills, contract awards, or government events by text and filters. However, there is no explicit guidance about when to use search_awards, search_opportunities, or latest_events instead, nor any 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, so the safety profile is covered. The description adds useful behavioral context about the exact notice types and filterable attributes, but it does not mention pagination, result ordering, or return structure. With annotations bearing the safety burden, this is adequate but not exceptional.

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 focused sentences carry the full meaning: the first defines the resource and scope, the second lists the filter dimensions. There is no filler, repetition, or unnecessary 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 read-only search tool with a fully documented schema and no output schema, the description provides enough context about what is searched and how to narrow results. It could add return-format or pagination notes, but the absence does not leave the agent unable to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds a high-level grouping of filters ('keyword, NAICS, agency, notice type, date') that help orientation but do not provide parameter-level detail beyond what the schema already offers. Baseline 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 opens with a specific verb and resource: 'Search SAM.gov notices.' It then enumerates the notice types covered (Sources Sought, Pre-solicitations, solicitations, combined synopses), which clearly distinguishes this from sibling tools like search_awards or search_bills. The title reinforces the domain without ambiguity.

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 clear context by framing these notices as 'the earliest public signal of a purchase,' so an agent can infer this is the tool for pre-award opportunities. It does not explicitly name alternatives or say when not to use it, but the scope is specific enough that the intended use case is evident.

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, so the description is not required to restate safety. It adds meaningful behavioral detail: the data source is FEC committee totals, different parameters switch the output mode, committee profiles include donors, candidate spending, and vendors, and public companies are resolved to tickers. It does not disclose pagination or exact response shape, but the main behaviors are transparent.

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

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

The description is longer than average, but the tool has multiple distinct modes and ten parameters, so the detail is largely justified. It is front-loaded with the primary ranking purpose, then systematically covers each mode, and ends with concrete question examples. A few phrases are redundant with later examples, giving it a 4 rather than a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing return behavior, and it does so at a useful level: committee lists, committee profiles with donors/candidates/vendors, shared vendor lists, and public company rankings. It does not specify exact response fields, potential mode conflicts, or edge cases like invalid committee ids, but for an agent selecting and invoking the tool it is largely sufficient.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds essential interaction semantics that the schema alone does not convey: query/committee_id trigger a committee profile, shared_vendors switches to vendor sharing, public_companies switches to ticker-ranked companies, and ticker/min_committees are only meaningful within those modes. This goes well beyond individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (super PACs) and a set of specific verbs/behaviors: ranking committees by money raised/spent/on hand, returning a committee profile with donors and expenditures, listing shared vendors, and ranking public companies by political contributions. It clearly distinguishes the tool's multi-modal scope from generic political money tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides strong usage context through conditionals: 'With query or committee_id', 'With shared_vendors', and 'With public_companies', and it gives representative natural-language questions to match against. However, it does not explicitly name sibling alternatives like outside_money or pac_lookup, nor state when this tool should not be used.

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 declare readOnlyHint=true and idempotentHint=true, which signal safety and repeatability. The description 'No description available.' does not contradict these annotations. However, the description adds zero behavioral context beyond the annotations. With annotations covering the safety profile, no contradiction exists, and a baseline 3 is appropriate since the description neither helps nor hurts behavioral transparency.

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?

An empty description is under-specification, not conciseness. There is no information to evaluate for front-loading or sentence economy. A single title line plus 'No description available' does not constitute a structured definition. This is not concise; it is absent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is completely inadequate. Even with a 0-parameter schema and read-only annotations, the tool name 'track_record' plus title 'HillSignal forward track record' suggest a dataset, but no explanation of what 'forward calls' means, what data is returned, or how it relates to sibling tools. An agent cannot correctly invoke or interpret this tool's results. Completeness is essentially zero.

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 0 parameters, so there is nothing to document. Baseline 4 applies for tools with no parameters. The description says 'No description available,' which is irrelevant here since no parameter semantics are needed. The schema itself fully defines the calling contract with an empty object.

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 is empty for this tool. The title 'HillSignal forward track record' identifies a resource-specific metric, but no description exists. The description says 'No description available.' This is a tautology that restates the title without any verb or resource-specific action. An agent cannot determine what this tool does from the description alone, especially alongside 14 sibling tools covering similar political finance data types. Purpose clarity fails completely.

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?

There is zero guidance on when to use this tool vs. siblings. No context about whether this is a read-only lookup, a summary statistic, or a queryable dataset. With 14 sibling tools covering PACs, politicians, insider trades, and other data, an agent has no way to route to this tool correctly. No usage guidance whatsoever.

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