Server Quality Checklist

Tool Scores

• federal_awardsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation is a lookup (implying read-only), names the data source, and lists the returned fields. However, it does not mention data freshness, potential delays, match semantics, or output format beyond the field names, leaving some behavioral aspects undisclosed.

  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 with no filler. The first sentence front-loads the core action, resource, source, and data included; the second adds a relevant use case. Every word contributes to the agent's understanding.

  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 low complexity (4 params, 1 required, no nested objects) and full schema coverage, the description is largely complete. It names the data source, what data is returned, and the intended use case. The absence of an output schema is mitigated by the mention of amounts, agencies, and dates, though it could be slightly clearer that the result is a list of award records.

  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%, so the baseline is 3. The description adds minimal semantic value beyond the schema: it suggests recipientName refers to a U.S. company and highlights contracts/grants/loans, which partially overlaps with the awardTypes parameter values. It does not clarify maxResults or sinceFiscalYear beyond what the schema already provides.

  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 starts with a specific verb ('Look up') and clearly identifies the resource ('U.S. company's federal contracts, grants, and loans') plus the data included (amounts, agencies, dates). It also names the authoritative source (USAspending.gov), making the tool easily distinguishable from sibling tools like business_search and watchlist_screen.

  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 specifies a clear context: 'Useful for B2G sales intel and due diligence.' However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternative sibling tools for related use cases. The usage context is implied from the use-case sentence, but no exclusions or routing is given.

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

• business_searchA
  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 behavioral burden and does well by disclosing the output: 'registration records (status, dates, registered agent)' and clarifying matching behavior. It does not cover potential rate limits, data freshness, or error conditions, but for a read-only search tool these are minor gaps.

  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 pack the core purpose, scope, output, and name-matching behavior with no filler. The most important information is front-loaded, making it easy for an agent to scan and act on.

  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 search tool with a well-defined schema, the description is reasonably complete: it covers purpose, scope, return content, and name matching. It lacks an output schema, so the explicit mention of returned fields helps, but it could still clarify state coverage details or absence-of-results behavior.

  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 covers all 4 parameters with descriptions, so the baseline is 3. The description adds only minor value beyond the schema by restating that full or partial names are accepted; it does not clarify states, exactMatch, or maxResultsPerState beyond what the schema already provides.

  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 specifies a clear action ('Look up'), a precise resource ('U.S. company's official Secretary of State business registration'), and a bounded scope ('across 25 states (KYB)'). This differentiates it from sibling tools like new_business_filings and watchlist_screen, which clearly serve different purposes.

  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 implies when to use this tool (when you need official business registration records and status), but it does not explicitly state when not to use it or mention alternatives. It gives a useful hint with 'Use the full or partial company name,' but lacks direct routing among the sibling tools.

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

• new_business_filingsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden and does add useful context: the data is pulled from official state sources, limited to 10 states, and filtered by a date window, implying a read-only retrieval. However, it does not describe return shape, pagination, or data freshness caveats beyond what the schema already hints at.

  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 tight sentences with no filler: the scope is front-loaded, then the use case follows. Every clause contributes.

  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 definition is complete enough to select and invoke the tool given full schema param docs and zero required params. The main gap is the absence of an output schema and any statement about what the returned filings contain, which would improve invocation confidence.

  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 covers all four parameters with descriptions, examples, and constraints (coverage is 100%), so the description adds little param-specific value. Its mention of 'windowed by date' is redundant with the daysBack/sinceDate parameters.

  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?

  States a specific action ('Pull'), a defined resource ('newly registered U.S. businesses'), and concrete scope ('official state sources (10 states)' + date window). The recency and source make it easy to distinguish from siblings like business_search or federal_awards.

  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?

  Gives explicit intended use cases: sales-lead feeds and monitoring brand-new companies. It does not explicitly say when not to use it or point to an alternative tool, so it falls just short of full routing guidance.

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

• watchlist_screenA
  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 behavioral disclosure burden. It clearly discloses fuzzy matching, name-based matching, return of matched records, and the risk that hits are not identity confirmation. It could add output field or rate-limit details, but the key behavioral caveat is well covered.

  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 dense, front-loaded sentences. The first scopes the tool and names its data sources; the second states the return behavior and adds the essential verification caveat. No filler.

  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 five-parameter tool with no annotations and no output schema, the description plus fully documented schema is sufficient for an agent to select and invoke it correctly. A minor gap is the lack of an explicit read-only/no-side-effect statement, though 'screen' and 'returns' strongly imply 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?

  Schema coverage is 100%, so the input schema already documents all five parameters. The description reinforces the fuzzy-match behavior tied to minScore and includeAliases, but does not add substantial meaning beyond the schema, so 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?

  States a specific action (screen) against a specific resource (person/business name against 12 U.S. government watchlists via the Consolidated Screening List). Enumerated list sources make the scope concrete and clearly distinguish it from sibling tools like business_search or federal_awards.

  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?

  Provides clear context for when to use: name-based watchlist screening. The NOTE adds an important boundary (not identity confirmation, verify before acting), but it does not explicitly name alternative tools or state conditions that should route the agent elsewhere.

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