Server Quality Checklist

Tool Scores

• get_corporate_registryA
  4.3/5.0
  Behavior3/5

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

  No annotations provided, so description bears full burden. Discloses potential no-results, but does not mention rate limits, data freshness, or auth requirements. Adequate but not thorough.

  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?

  Three concise sentences; purpose is front-loaded. No superfluous words. Efficient and structured.

  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?

  Despite no output schema, description enumerates returned data fields (incorporation date, etc.) and covers edge case (no results). Sufficient for a simple lookup tool.

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

  Parameters4/5

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

  Schema covers 100% of the single parameter with clear description. Description adds value by suggesting suffixes improve accuracy, going beyond schema details.

  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?

  Clearly states lookup of corporate registry data from OpenCorporates, specifying data types (incorporation date, status, etc.) and coverage (140+ jurisdictions). Distinguishes from siblings like get_financials or get_key_people.

  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 best practice (use legal name) and acknowledges possible no-results for new/small companies, but does not explicitly contrast with sibling tools or state when to prefer this over alternatives.

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

• get_key_peopleA
  4.4/5.0
  Behavior4/5

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

  Describes the scraping process (website, Wikipedia, GitHub), the data returned (names, titles, sources). With no annotations, this is sufficient behavioral disclosure. Could be improved by mentioning potential failure modes or rate limits, but overall transparent.

  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?

  Three sentences concisely cover purpose, method, use case, and requirement. No extraneous words. Front-loaded with the main action.

  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 a single parameter and no output schema, the description covers the essential aspects: input, process, output, and use case. It could be more complete by mentioning limitations (e.g., only public info, or if site blocks scraping), but it's largely adequate.

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

  Parameters4/5

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

  Schema covers the single parameter 'domain' at 100%. The description adds further context: 'without protocol (e.g. 'openai.com')' and explains how the domain is used (scraping about/team pages). This adds value beyond the schema.

  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?

  Clearly defines the tool as finding key people (founders, C-suite, team members) at a company. Differentiates from sibling tools like get_company_news or get_financials by focusing specifically on leadership and team information.

  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?

  Explicitly states when to use: 'when you need leadership or team information specifically.' Also specifies a prerequisite: 'Requires a domain name.' Does not provide explicit exclusions or alternatives, but the context is clear enough.

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

• get_company_newsA
  4.5/5.0
  Behavior4/5

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

  Discloses returned data (titles, descriptions, sources, dates sorted by recency) and the dependency on server-side API key configuration. No annotations provided, but description adequately covers behavioral expectations.

  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?

  Three sentences: purpose and sources, returned fields, usage note + caveat. Every sentence earns its place; no redundancy.

  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?

  For a simple news-fetching tool with one parameter and no output schema, the description covers input requirements, return content, sorting, and external dependencies. No critical gaps.

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

  Parameters4/5

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

  Schema covers 100% of the single parameter with description. Description adds value by providing examples ('Anthropic', 'OpenAI', 'Tesla') and reinforcing the 'not domain' constraint, exceeding baseline.

  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?

  Clearly states 'Get recent news articles about a company' with specific sources (Brave Search and NewsAPI). Precisely describes the action and resource, distinguishing it from sibling tools that handle corporate registry, financials, or people.

  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?

  Explicitly instructs to use company name, not domain, and mentions API key dependency. Lacks explicit guidance on when to prefer this tool over alternatives, but context is sufficiently implied.

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

• get_tech_stackA
  4.5/5.0
  Behavior4/5

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

  The description discloses the analysis methods (HTTP headers, DNS, GitHub) and return content, but does not mention any side effects, rate limits, or authentication requirements. Since no annotations are provided, the description carries the full burden; it is mostly transparent but lacks explicit safety or non-destructive confirmation.

  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 three sentences, each adding distinct value: purpose and method, usage guidance and return types, and input constraint. No unnecessary words, front-loaded with key information.

  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 low complexity (1 parameter), full schema coverage, and no output schema, the description compensates by listing return types (frameworks, languages, etc.) and providing clear usage context. It is complete for an agent to correctly invoke the 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?

  With 100% schema coverage, the input schema already describes the 'domain' parameter adequately. The description reinforces the requirement but adds no new semantic meaning beyond confirming domain format and exclusion of company names.

  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 explicitly states 'Detect a company's technology stack' with specific methods (HTTP headers, DNS, GitHub) and return types (frameworks, languages, etc.). It distinguishes itself from the sibling 'lookup_company' tool, making the purpose clear and unique.

  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 guidance: 'Use this instead of lookup_company when you only need technology information' and 'Requires a domain name — company names are not supported.' This covers when to use, when not to, and an alternative.

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

• get_financialsA
  4.6/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 data sources (SEC EDGAR), scope (US public companies), and data freshness ('updated as companies file new reports'), which is adequate for a read-only data retrieval 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?

  The description is concise (three sentences), front-loaded with the core purpose, and every sentence adds value. No redundancy or fluff.

  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?

  With one simple parameter, no output schema, and clear scope, the description fully explains what the tool does, what data it returns, and its limitations. No additional information is needed.

  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 'company_name' is well-described in the schema (100% coverage). The description adds that both common names and ticker symbols are supported, which enhances semantic understanding beyond the schema.

  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 gets financial data for US public companies from SEC EDGAR, listing specific fields (revenue, net income, etc.). This distinguishes it from sibling tools like get_company_news (news) or get_corporate_registry (registry info).

  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 limits use to SEC-filing companies, stating private and non-US companies will return no results. It gives clear context but does not explicitly mention alternatives to this tool.

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

• lookup_companyA
  4.7/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses key behavioral traits: it aggregates data from multiple sources, returns JSON with confidence scores and source attribution, and notes that domains produce richer results. It could mention potential latency or failure modes, but overall is transparent enough.

  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 four sentences, each serving a purpose: purpose and sources, return fields, usage guidance, input format and note. No fluff, and critical information is front-loaded.

  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's complexity and lack of output schema, the description adequately covers input format, output structure (fields, confidence scores, source attribution), and usage context. It equips the agent to understand what the tool returns and when to invoke it.

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

  Parameters4/5

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

  Schema coverage is 100% with one parameter. The description adds valuable context beyond the schema: 'Domains produce richer results because they enable website scraping and DNS analysis.' This helps an agent choose between domain or company name.

  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: 'Get a comprehensive company profile by aggregating data from multiple sources.' It lists specific return fields and distinguishes itself from sibling tools by being the primary entry point that calls other data sources automatically.

  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?

  Explicit guidance: 'Use this as the primary entry point for any company research — it calls all other data sources automatically.' This tells the agent when to use this tool versus the more specific sibling tools like get_financials or get_tech_stack.

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