Server Quality Checklist

Tool Scores

• web.richC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions a two-step process (enable callback, then fetch data) which adds some context about the tool's workflow. However, it doesn't disclose important behavioral traits like whether this is a read/write operation, authentication requirements, rate limits, error conditions, or what happens during the callback flow.

  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 brief and to the point with two clear sentences. It efficiently describes the two-step process without unnecessary elaboration. However, it could be more front-loaded with the core purpose before detailing the implementation flow.

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

  Completeness2/5

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

  For a tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain what 'rich data' means, what the callback flow entails, what format results are returned in, or how this differs from the simpler web.search sibling tool. The description leaves too many open questions about the tool's behavior and output.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description doesn't mention the 'q' parameter at all, nor does it explain what this parameter represents (presumably a search query). No additional semantic information is provided beyond what the bare schema indicates.

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

  Purpose3/5

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

  The description states the tool performs 'Brave Rich Search via callback flow' with two steps: enabling rich callback and fetching rich data. This provides a general purpose but lacks specificity about what 'rich data' entails or what resource is being searched. It doesn't clearly distinguish from sibling tools like web.search.

  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?

  No explicit guidance on when to use this tool versus alternatives like web.search. The description mentions a 'callback flow' which might imply specific usage scenarios, but doesn't state when this approach is preferred over direct search methods or what distinguishes it from sibling tools.

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

• local.descriptionsC
  2.7/5.0
  Behavior2/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 mentions fetching descriptions for location IDs with a limit of 20, but doesn't specify what 'descriptions' contain (e.g., text, metadata), how results are returned, error handling, or any rate limits. This leaves significant gaps for a tool with one required parameter.

  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 a single, efficient sentence that front-loads the key action ('fetch descriptions') and constraint ('up to 20'). There's no wasted verbiage, though it could be slightly more structured (e.g., separating purpose from limitations).

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

  Completeness2/5

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

  Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what 'descriptions' entail (e.g., text summaries, attributes), how results are formatted, or any behavioral nuances. For a tool fetching data with a required parameter, more context is needed to guide effective use.

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

  Parameters2/5

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

  The schema has 0% description coverage, so the description must compensate. It only implies that 'ids' are 'location ids' and there's a limit of 20, but doesn't explain what format these IDs should be (e.g., numeric, alphanumeric), where they come from, or what happens if invalid IDs are provided. This adds minimal value beyond the schema's structural constraints.

  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?

  The description clearly states the verb 'fetch' and the resource 'descriptions for location ids', specifying the scope 'up to 20'. It distinguishes from siblings like 'local.pois' (likely points of interest) and web tools by focusing on descriptions for location IDs. However, it doesn't explicitly differentiate from all siblings (e.g., 'web.rich' might also provide descriptions).

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'local.pois' (which might return different location data) or 'web.search' (which might search more broadly). There's no context about prerequisites, limitations, or typical use cases.

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

• local.poisC
  2.8/5.0
  Behavior2/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 mentions the action ('fetch extra info') and a constraint ('up to 20 location ids'), but lacks critical details such as what type of information is returned, whether this is a read-only operation, potential rate limits, authentication requirements, or error handling. The description is too vague to fully inform agent behavior.

  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 extremely concise—a single sentence that efficiently communicates the core functionality and key constraint. Every word earns its place, with no redundant or unnecessary information, making it easy to parse and understand quickly.

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

  Completeness2/5

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

  Given the tool's complexity (1 parameter with 0% schema coverage, no annotations, and no output schema), the description is insufficiently complete. It fails to explain what 'extra info' includes, the format of the response, error conditions, or how this tool relates to siblings. For a data-fetching tool, this leaves too many unknowns for reliable agent operation.

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

  Parameters2/5

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

  The input schema has 0% description coverage, so the description must compensate. It only vaguely references 'location ids' for the 'ids' parameter without explaining what format these IDs should be (e.g., numeric, alphanumeric), where they come from, or what constitutes a valid location ID. This leaves significant ambiguity about parameter meaning and usage.

  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?

  The description clearly states the tool's purpose with specific verbs ('fetch extra info') and resources ('location ids'), and specifies the scope ('up to 20'). It distinguishes itself from generic search tools by focusing on supplementary data for existing IDs rather than discovery. However, it doesn't explicitly differentiate from sibling tools like local.descriptions, which might offer similar functionality.

  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 provides minimal usage guidance, only implying this tool should be used when you have location IDs and need additional information. It offers no explicit guidance on when to use this versus alternatives like local.descriptions or web.search, nor does it mention prerequisites or constraints beyond the ID count limit.

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

• web.searchC
  2.8/5.0
  Behavior2/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 of behavioral disclosure. It states the tool returns search results but lacks critical details: it doesn't mention rate limits, authentication needs, pagination, error handling, or whether it's read-only or mutative. For a web search tool with zero annotation coverage, this is a significant gap in transparency.

  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 extremely concise—a single sentence with no wasted words. It's front-loaded with the tool's core purpose ('Brave Web Search: returns results for query q'), making it easy to scan. Every part of the sentence earns its place by specifying the service and action.

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

  Completeness2/5

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

  Given the complexity (5 parameters, 2 with enums, no output schema, and no annotations), the description is incomplete. It doesn't explain return values, error cases, or behavioral constraints. For a search tool with multiple optional parameters and no structured guidance, the description should provide more context to help the agent use it effectively.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description only mentions 'query q', covering 1 of 5 parameters. It doesn't explain the semantics of count, country, safesearch, or freshness, nor does it clarify enum values (e.g., what 'pd' means for freshness). The description fails to compensate for the schema's lack of documentation.

  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?

  The description clearly states the tool's purpose: 'returns results for query q' using Brave Web Search. It specifies the verb ('returns results'), resource ('Web Search'), and distinguishes it from siblings like local.descriptions and local.pois by focusing on web search. However, it doesn't explicitly differentiate from web.rich, which might be a similar web-related tool.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose web.search over web.rich or local tools, nor does it specify any prerequisites, exclusions, or contextual usage scenarios. The agent must infer usage from the tool name alone.

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