Server Quality Checklist

Tool Scores

• get_candidate_moneyB
  3.2/5.0
  Behavior2/5

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

  No annotations are available, and the description only notes that 'requires WALLET_PRIVATE_KEY' and warns 'PAID ($0.01)'. It does not specify whether the operation is read-only, whether it deletes/overwrites data, rate limit, or side effects.

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

  Conciseness4/5

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

  A single efficient sentence, values are separated by dashes; important empty payment notice is leading.

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

  Completeness3/5

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

  Although the tool has a clear domain and data includes the cycle and office filter, there is no output cardinality/schema, and only a reduced indicator of auth. There are sibling tools, but not explicitly referenced.

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

  Parameters3/5

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

  The schema has 3 parameters and 67% coverage. The description adds the distinction 'fuzzy name vs exact ID', but otherwise 'optional office field' and parameter names and their descriptions are all you get. The description does not fully fill the missing schema entries.

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

  Purpose4/5

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

  Description begins with 'PAID ($0.01)' and specifies a concrete action and object: 'Campaign finance totals for a US federal candidate: receipts, spending, cash on hand, debts, individual vs PAC split, per recent cycle.' It clearly identifies the subject matter and lists concrete fields. Differentiates from siblings by finance focus, but no explicit comparison to other tools.

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

  Usage Guidelines3/5

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

  The description states that you pass a name (fuzzy) or exact candidate_id, and says office preference is optional. It does not explicitly explain when to choose one tool over siblings, nor does it specify any alternative.

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

• search_lobbyingA
  3.5/5.0
  Behavior3/5

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

  The description discloses the cost, key requirement, and returned data fields. However, it does not mention whether the operation is read-only, any rate limits, pagination behavior, or potential side effects, leaving some behavioral ambiguity.

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

  Conciseness4/5

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

  The description is concise and well-structured, covering the essential aspects in one sentence with clear separation of cost, function, and requirement. It avoids unnecessary fluff.

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

  Completeness4/5

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

  Given the lack of an output schema, the description sufficiently explains what data will be returned (income, issue areas, text, lobbyists). It does not mention pagination or result ordering, but for a search tool of this simplicity, the provided context is adequate.

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

  Parameters3/5

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

  The schema already provides descriptions for each parameter. The tool description adds minimal extra meaning by indicating that client and registrant correspond to 'client company' and 'lobbying firm', but it does not clarify how to combine them or whether any are required.

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

  Purpose5/5

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

  The description clearly states the tool's function: retrieving US federal lobbying filings by client or lobbying firm, and specifies the data returned (income, issue areas, specific-issue text, named lobbyists). It is distinct from sibling tools like search_federal_contracts.

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

  Usage Guidelines2/5

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

  The description lacks guidance on when to use this tool versus alternatives. It only mentions the cost and required key, but does not explain scenarios where this search is preferred or when other tools would be more appropriate.

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

• get_endpoint_specA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool makes a 'live call' to fetch spec from the service's OpenAPI doc, explains it is free, and outlines the two output modes. It does not mention error handling or rate limits, but the core behavior is transparent enough for a read-only spec tool.

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

  Conciseness5/5

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

  Two sentences, each adding value: the first front-loads the free/no-wallet differentiator and what the tool returns, the second explains the two call modes. No fluff or redundancy, making it easy to parse quickly.

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

  Completeness4/5

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

  For a simple tool with no output schema, the description explains the expected return content (price, input JSON schema, worked examples) and covers both invocation patterns. It doesn't describe the response format in detail, but that's not critical for a specification tool. The description is sufficient for an agent to understand when and how to use it.

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

  Parameters3/5

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

  The single optional 'path' parameter has 100% schema description coverage, including an example ('congress-stock-trades'). The description adds that passing a path yields 'full detail', but this is a minor enhancement over the schema's own description. Baseline of 3 applies since the schema already documents the parameter well.

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

  Purpose5/5

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

  The description clearly states the tool provides 'Live call spec for the gov-transparency routes: price, input JSON schema, and worked request/response examples from the service's OpenAPI doc.' This verb+resource construction is specific and distinct from sibling data-fetching tools, and it mentions the exact scope of routes.

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

  Usage Guidelines4/5

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

  It gives explicit usage instructions: 'Call with no arguments to list all nine routes, or pass a path for full detail.' This tells the agent when to use each form, though it does not explicitly contrast with sibling tools or state when not to use it. The 'FREE — no wallet needed' note also informs preconditions.

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

• get_trade_filingsA
  4.2/5.0
  Behavior4/5

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

  The description prominently discloses the cost ('PAID ($0.01)') and the authentication requirement ('Requires WALLET_PRIVATE_KEY'), which are critical operational behaviors. Since no annotations are provided, the description carries the full transparency burden, and it does a good job with these essentials, though it doesn't cover rate limits or pagination intricacies.

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

  Conciseness5/5

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

  The description is a single dense but efficient sentence, front-loading the cost and purpose, then enumerating key fields and a usage hint. No filler or redundancy; every clause adds value.

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

  Completeness4/5

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

  Given the modest complexity, full schema coverage, and no output schema, the description covers the essentials: purpose, cost, auth, key usage pattern. It doesn't describe response format, but that's not required if output schema exists (it doesn't, but the tool is a simple index listing). It could mention pagination beyond limit, but otherwise it's fairly complete.

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

  Parameters3/5

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

  The schema already provides thorough parameter descriptions (coverage 100%), including defaults and examples. The description adds semantics around filing_type 'P' for trades, which is a useful hint, but otherwise the schema does the lifting, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description is highly specific: 'US House financial-disclosure filing index' with a clear enumeration of what it returns (filer, district, type, date, PDF link) and a distinct verb ('Poll'). It clearly distinguishes from siblings like get_congress_trades by focusing on the filing index rather than summarized trade data.

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

  Usage Guidelines4/5

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

  The description gives a concrete use case: 'Poll filing_type 'P' to catch fresh trade disclosures early.' This is actionable guidance. However, it doesn't explicitly state when NOT to use it or mention alternatives like get_congress_trades, though the sibling context implies differentiation.

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

• search_federal_contractsA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the paid nature (PAID ($0.01)) and the requirement for WALLET_PRIVATE_KEY, which is critical for invocation. It does not mention pitfalls like rate limits or error handling, but the cost and auth are transparently stated.

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

  Conciseness5/5

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

  The description is a single sentence packed with essential information: cost, output fields, sorting, filters, and auth requirement. It is front-loaded with the most critical detail (PAID) and is highly efficient.

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

  Completeness4/5

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

  With 5 parameters and no output schema, the description does a good job covering what is returned, sorting, filters, cost, and auth. It lacks explicit notes on pagination or limit defaults (though limit is in schema) but is otherwise complete for a search tool.

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

  Parameters3/5

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

  Schema description coverage is 100% (all parameters have descriptions). The description adds context about filters and output fields but does not add new semantics beyond what the schema already provides. Baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it searches federal contract awards by company, listing output fields (award id, amount, agency, dates, description, link) and sorting order (largest first). It distinguishes from siblings like get_contractor_profile by explicitly mentioning award-specific data and filters.

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

  Usage Guidelines4/5

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

  The description mentions optional agency and date-window filters, giving context on how to narrow searches. It doesn't explicitly reference sibling tools, but the scope (awards by recipient) is clear enough to differentiate from related tools like get_contractor_profile.

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

• lookup_billA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full transparency burden. It discloses the cost ($0.005) and auth requirement (WALLET_PRIVATE_KEY), which are critical behavioral traits. It also specifies the output content. It does not mention side effects, but as a read-only lookup, the 'official status' implies safe operation. Slight gap on pagination or error handling, but adequate for a simple lookup.

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

  Conciseness5/5

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

  The description is a single, information-dense sentence that front-loads the purpose and cost, then details output and addressing, and closes with the auth requirement. No redundant words or filler. Every clause adds value.

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

  Completeness5/5

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

  Given the tool has only 3 parameters and no output schema, the description covers the purpose, return data, addressing, cost, and auth. It is sufficiently complete for an agent to understand what the tool does and how to invoke it. No missing critical information for a simple lookup tool.

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

  Parameters3/5

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

  Schema coverage is 100%, so each parameter already has a description. The tool description adds a general addressing pattern ('Address by congress number, type..., and bill number') and lists type examples, but these largely duplicate the schema. It provides a bit of context but does not significantly enrich beyond the schema, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function: retrieving official status of a US Congress bill, specifying the exact data returned (title, sponsor, latest action, etc.). It distinguishes itself from siblings by topic (bill lookup vs. trades, filings, contracts). The verb 'lookup' plus resource 'bill' is specific.

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

  Usage Guidelines4/5

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

  The description implicitly tells when to use: when you need bill status. It also provides prerequisites: requires WALLET_PRIVATE_KEY and costs $0.005, which are important usage conditions. It doesn't explicitly mention alternatives, but siblings are unrelated, so no exclusions needed. Overall clear context.

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

• find_candidateA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool is paid ($0.005), requires a private key, and returns specific fields. It does not discuss failures or side effects, but for a read-only search, this is adequate. The cost and auth disclosures are valuable beyond what structured data would imply.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the purpose and key return fields, then usage context. No wasted words; every sentence provides necessary information. Excellent conciseness.

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

  Completeness4/5

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

  The description explains what it returns (list of fields), the cost, and the auth requirement. It references the next logical tool (get_candidate_money). It does not detail error handling or pagination, but for a simple search with a single parameter and no output schema, it covers the essential context. Slightly incomplete regarding edge cases but acceptable.

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

  Parameters3/5

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

  The input schema covers 100% of the single parameter with a clear description ('Candidate name, min 3 chars'). The tool description adds little beyond the schema—it repeats the 'by name' aspect and mentions min 3 chars, which is already in the schema. The returned fields are useful context but not parameter semantics. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: search US federal candidates by name and return specific fields (candidate ids, party, office, etc.). It explicitly distinguishes itself as the 'cheap resolver before get_candidate_money', which differentiates it from sibling tools, especially the related get_candidate_money.

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

  Usage Guidelines5/5

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

  The description provides explicit usage context: it is positioned as a preprocessing step before get_candidate_money, implying when to use it (for cheap candidate lookups before expensive money queries). It also states the auth requirement (WALLET_PRIVATE_KEY) and cost, giving clear operational prerequisites.

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

• get_congress_tradesA
  4.4/5.0
  Behavior4/5

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

  The description indicates this is a read-only retrieval operation (parsing and returning trades) and mentions the requirement of a WALLET_PRIVATE_KEY for access. It does not explicitly state that there are no side effects, but the nature of the operation is clear. The disclosure lag is a behavioral aspect that is transparently communicated.

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

  Conciseness4/5

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

  The description is concise but includes necessary information: purpose, fields, filters, lag, and key requirement. It is structured logically with separate sentences for the main function, filtering, lag, and authentication. The leading 'PAID ($0.02) —' adds a minor cost indicator but does not detract from clarity.

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

  Completeness4/5

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

  Given the lack of an output schema, the description provides enough context by listing the data fields (ticker, asset, buy/sell, transaction date, amount range) to let the agent infer the return structure. It also covers filtering options and the disclosure lag. However, it does not describe edge cases or error behavior, which is acceptable for a simple query tool.

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

  Parameters5/5

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

  All parameters have clear descriptions in the schema: type is an enum with allowed values, limit specifies max rows, since/until are ISO date bounds, state is a prefix, member is a substring, and ticker is exact. Each description includes examples (e.g., 'wittman', 'NVDA') to illustrate expected input, providing high semantic clarity.

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

  Purpose5/5

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

  The description clearly states that the tool parses congressional stock trades from official STOCK Act disclosures and lists the specific data fields (ticker, asset, buy/sell, transaction date, amount range). It specifies the scope as US House member trades and distinguishes it from sibling tools like get_trade_filings by focusing on trade data rather than filings.

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

  Usage Guidelines4/5

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

  The description explicitly mentions filterable parameters (member name, ticker, trade type, state, date window) and notes the 45-day disclosure lag, which is crucial for interpreting data freshness. It doesn't explicitly state when to use this over alternatives, but the focus on trades versus filings provides implicit guidance.

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

• get_contractor_profileA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the cost ($0.01) and auth requirement (WALLET_PRIVATE_KEY), which are key operational traits. It doesn't explicitly state read-only behavior, but the nature of a lookup and the fields listed imply no mutations. It adds useful context beyond what structured data would provide.

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

  Conciseness5/5

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

  Two sentences: first states purpose and data items, second gives usage and auth. No redundancy, front-loaded with the most important info (paid cost). Every word earns its place.

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

  Completeness4/5

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

  For a 2-param, no-output-schema tool, the description covers purpose, usage, cost, and auth. It lists the returned fields sufficiently. Minor gaps: no mention of error handling or pagination behavior, but the 'limit' param is documented in schema. Overall, it's complete enough for typical use.

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

  Parameters3/5

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

  Input schema covers both parameters with descriptions (100% coverage). The description does not add additional semantics beyond the schema, but that's fine since schema is sufficient. Baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Resolve a company name to its official federal recipient records' and lists specific fields (legal name, UEI, parent/child level, recent federal award totals, profile link). It distinguishes from sibling 'search_federal_contracts' by positioning as a disambiguation step.

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

  Usage Guidelines5/5

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

  Explicitly says 'Use before search_federal_contracts to disambiguate entities,' giving clear usage context relative to a specific sibling tool. Also notes the requirement for WALLET_PRIVATE_KEY, which is a prerequisite.

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

• watch_federal_registerA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the paid nature ($0.005), the required wallet key, the return fields, and the ordering (newest first). It also mentions the empty-query behavior. This exceeds minimal transparency, though it could mention rate limits or pagination.

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

  Conciseness5/5

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

  The description is one concise sentence, yet packs in cost, topic, types, output fields, and null-query behavior. No fluff or unnecessary words. It's well-structured and easy to parse.

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

  Completeness4/5

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

  The description provides cost, auth requirement, and output details, plus the empty-query fallback. It lacks info on limits, errors, or date ranges, but for a simple search, it's adequately complete. The absence of annotations raises the bar, and it meets it reasonably.

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

  Parameters5/5

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

  The single parameter q is clearly described as a search term with an example ('stablecoin'). The description explains that an empty query returns government-wide results, which fully covers the optional parameter's semantics. Schema coverage is 100%.

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

  Purpose5/5

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

  The description clearly states the tool returns the newest US regulations and official notices matching a topic, with specific content types (proposed/final rules, executive orders, notices) and output fields (agency, date, abstract, links). This differentiates it from siblings like search_federal_contracts or get_congress_trades, which focus on different domains.

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

  Usage Guidelines4/5

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

  The description tells when to use it (to get regulatory updates on a topic) and notes the optional query (empty returns latest government-wide). While it doesn't explicitly name alternatives, the sibling list and domain-specific wording imply it's the go-to for federal regulations. It also warns about cost and wallet key requirement, adding practical context.

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