Server Quality Checklist

Tool Scores

• show_api_keyB
  3/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. It mentions the tool returns a bearer token for debugging, but it doesn't disclose behavioral traits such as security implications, whether it exposes sensitive data, or any rate limits. This is a significant gap for a tool handling authentication tokens.

  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 states the purpose and usage context without waste. It's appropriately sized for a simple tool, though it could be slightly more structured by separating purpose from context.

  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 of handling authentication tokens, the description is incomplete. No annotations or output schema exist, and it fails to cover security risks, return format, or error handling. This leaves the agent with insufficient information for safe and effective use.

  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?

  The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, which is acceptable here. Baseline is 4 since there are no parameters to compensate for, and the description doesn't contradict the schema.

  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 action ('Return') and the resource ('bearer token from the Authorization header of the MCP settings'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools, which are unrelated to API key retrieval, so it doesn't reach the highest score.

  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 includes a usage context ('used to debug'), which implies when to use it, but it lacks explicit guidance on when not to use it or alternatives. No sibling tools are directly related, so no comparison is provided, leaving gaps in usage instructions.

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

• expand_queryB
  3.2/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 mentions that the tool 'returns multiple expanded queries' and uses 'an up-to-date query expansion model,' which gives some context on output and methodology. However, it doesn't cover critical aspects like rate limits, error handling, or whether this is a read-only operation (implied but not stated). For a tool with no annotations, this leaves significant gaps in behavioral understanding.

  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 appropriately sized with two sentences that efficiently convey the tool's function and utility. It's front-loaded with the core purpose and avoids unnecessary details. However, the second sentence could be slightly more concise (e.g., 'Useful for deeper research by broadening search scope.'), but overall, it's well-structured with minimal waste.

  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?

  Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It explains what the tool does and its use case but lacks details on output format (e.g., structure of expanded queries), behavioral constraints, or integration with sibling tools. Without an output schema, more information on return values would be beneficial, making it adequate but not fully comprehensive.

  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 has 100% description coverage, with the 'query' parameter well-documented as 'The search query to expand (e.g., 'machine learning', 'climate change').' The description adds minimal value beyond this, only reiterating that it takes 'an initial query.' According to the rules, with high schema coverage (>80%), the baseline is 3 even without additional param info in the description.

  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: 'Expand and rewrite search queries based on an up-to-date query expansion model.' It specifies the verb (expand/rewrite) and resource (search queries), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'parallel_search_web' or 'search_web', which might also involve query processing, so it misses the highest score.

  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 provides implied usage context: 'Useful for improving deep research results by searching broader and deeper.' This suggests when to use it (for deeper research) but doesn't explicitly state when not to use it or name alternatives among the many sibling search tools. It offers some guidance but lacks clear exclusions or comparisons.

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

• parallel_search_ssrnB
  3.3/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 but provides minimal behavioral disclosure. It mentions 'for best results' and 'maximum 5 searches for optimal performance' (which is also in the schema), but doesn't describe what happens when searches complete, error handling, rate limits, authentication needs, or what format results return. For a parallel search tool with no annotations, this is inadequate.

  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 appropriately sized with three sentences that each serve a purpose: stating the tool's function, providing usage guidance, and suggesting query generation methods. It's front-loaded with the core purpose and avoids unnecessary elaboration.

  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 parallel search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what results look like, how parallel execution works, error handling, or performance characteristics. The description should provide more context about the tool's behavior given the lack of structured metadata.

  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 schema already fully documents both parameters. The description adds minimal value beyond the schema - it suggests 'provide multiple search queries that explore different research angles' which reinforces the 'searches' array parameter, but doesn't provide additional semantic context about parameter usage or interactions.

  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 'runs multiple SSRN searches in parallel' for 'comprehensive social science research coverage', which is a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'search_ssrn' (which appears to be a single search tool) or 'parallel_search_arxiv' (which searches a different database), missing full sibling differentiation.

  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 provides clear context for when to use this tool ('for comprehensive social science research coverage and diverse academic angles') and suggests using 'expand_query' to generate diverse queries. It implies this is for multiple parallel searches rather than single searches, but doesn't explicitly state when NOT to use it or name alternatives like 'search_ssrn'.

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

• capture_screenshot_urlA
  3.6/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. While it mentions the output format (base64 JPEG), it doesn't cover critical aspects like performance implications (e.g., speed differences between firstScreenOnly options), potential failures (e.g., timeouts, unsupported sites), authentication needs, or rate limits. The description is insufficient for a mutation-like tool (capturing external resources).

  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 efficiently structured in two sentences: the first states the core functionality and output format, the second provides usage scenarios. Every sentence adds value with zero wasted words, making it easy to parse and front-loaded with essential information.

  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 (interacting with external websites, multiple parameters) and lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like error handling, performance, or security considerations, which are crucial for a tool that captures web content. The description should provide more context to compensate for missing structured data.

  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 schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain trade-offs between firstScreenOnly options or when to use return_url). Baseline 3 is appropriate when the schema does the heavy lifting.

  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 with specific verbs ('capture screenshots') and resources ('web pages'), specifying the output format ('base64 encoded JPEG format'). It distinguishes from sibling tools like 'read_url' or 'search_web' by focusing on visual capture rather than text extraction or search.

  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 provides clear context for when to use the tool ('visually inspect a website, take a snapshot for analysis, or show users what a webpage looks like'), giving practical scenarios. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., 'read_url' for text content).

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

• parallel_read_urlA
  3.6/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. While it mentions 'extract clean content efficiently' and 'optimal performance' with a maximum of 5 URLs, it doesn't disclose important behavioral traits like error handling (what happens if a URL fails?), rate limits, authentication needs, or what 'clean content' specifically means. The description adds some context but leaves significant gaps for a tool that performs web requests.

  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 appropriately sized with three sentences that each serve a purpose: stating the core function, providing usage guidance, and explaining benefits. It's front-loaded with the main purpose first. While efficient, the third sentence could be slightly more concise by combining the two use cases.

  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?

  Given no annotations and no output schema, the description should do more to compensate. It adequately covers the purpose and basic usage but lacks details about behavioral traits, error handling, and what 'clean content' extraction entails. For a web reading tool with potential complexity around failures and content processing, this leaves important gaps despite the good schema coverage.

  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 schema already fully documents both parameters (urls array with maxItems:5 and timeout with default). The description adds marginal value by reinforcing the 'multiple URLs' concept and 'optimal performance' with up to 5 URLs, but doesn't provide additional semantic meaning beyond what's in the schema descriptions.

  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: 'Read multiple web pages in parallel to extract clean content efficiently.' It specifies the verb ('read'), resource ('multiple web pages'), and key behavior ('in parallel'), distinguishing it from sibling tools like 'read_url' (singular) and 'parallel_search_web' (searching rather than reading/extracting).

  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 provides clear context for when to use this tool: 'For best results, provide multiple URLs that you need to extract simultaneously' and 'useful for comparing content across multiple sources or gathering information from multiple pages at once.' It implies this is for parallel extraction of multiple pages, but doesn't explicitly state when NOT to use it or name alternatives like 'read_url' for single URLs.

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

• parallel_search_arxivA
  3.6/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 mentions 'parallel' execution and 'optimal performance' with max 5 searches, which adds useful context beyond the schema. However, it doesn't describe important behavioral aspects like error handling, rate limits, authentication needs, or what the output format looks like (especially critical since there's no output schema).

  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 appropriately sized with three sentences. The first sentence states the core purpose, the second provides usage guidance, and the third offers implementation suggestions. There's no wasted text, though the structure could be slightly more front-loaded with the most critical information.

  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?

  For a tool with 2 parameters, 100% schema coverage, but no annotations and no output schema, the description is adequate but has gaps. It covers the parallel execution concept and query diversity guidance, but doesn't address what the tool returns (critical without an output schema) or important behavioral constraints. The description compensates somewhat but not fully for the missing structured data.

  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 schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'multiple search queries' which aligns with the 'searches' array parameter, but doesn't provide additional semantic context about parameter usage or interactions that isn't already in the schema descriptions.

  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: 'Run multiple arXiv searches in parallel for comprehensive research coverage and diverse academic angles.' It specifies the verb ('run'), resource ('arXiv searches'), and scope ('in parallel'), but doesn't explicitly differentiate from its sibling 'search_arxiv' beyond the parallel execution aspect.

  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 provides clear context about when to use this tool: 'For best results, provide multiple search queries that explore different research angles and methodologies.' It also mentions an alternative tool ('expand_query') for query generation, though it doesn't explicitly contrast when to use this versus the regular 'search_arxiv' sibling tool.

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

• parallel_search_webA
  3.6/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 mentions 'parallel' execution and 'comprehensive topic coverage and diverse perspectives,' which hints at performance characteristics and intent. However, it doesn't disclose critical behavioral traits like rate limits, authentication needs, error handling, or what happens when searches fail. The description adds some context about optimal performance ('maximum 5 searches') but lacks comprehensive behavioral transparency for a tool with potentially complex execution.

  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 appropriately concise with three sentences that each serve a purpose: stating the tool's purpose, providing usage guidance, and mentioning an alternative tool. It's front-loaded with the core functionality. There's minimal waste, though the second sentence could be slightly more direct. Overall, it's efficiently structured for quick comprehension.

  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?

  Given the tool's complexity (parallel execution, multiple parameters), lack of annotations, and no output schema, the description is moderately complete. It covers the purpose and basic usage but misses important contextual details: what the output looks like (no output schema), error conditions, performance guarantees, or how results from parallel searches are combined. For a tool with significant operational complexity, the description should provide more complete context about behavior and results.

  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 schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It generically mentions 'provide multiple search queries' which aligns with the 'searches' parameter but doesn't provide additional semantics, syntax examples, or constraints. Baseline 3 is appropriate when the schema does all the parameter documentation work.

  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: 'Run multiple web searches in parallel for comprehensive topic coverage and diverse perspectives.' It specifies the verb ('Run multiple web searches in parallel') and resource ('web searches'), but doesn't explicitly distinguish it from sibling tools like 'search_web' or 'parallel_search_arxiv' beyond mentioning 'web' in the name and description. The purpose is clear but sibling differentiation is implicit rather than explicit.

  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 provides clear usage context: 'For best results, provide multiple search queries that explore different aspects of your topic.' It also mentions an alternative tool: 'You can use expand_query to help generate diverse queries.' However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'search_web' or 'parallel_search_arxiv', nor does it cover prerequisites or exclusions beyond the implicit parallel nature.

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

• search_arxivA
  3.6/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. While it mentions the tool is 'perfect for finding research papers' and lists use cases, it lacks critical behavioral details such as rate limits, authentication requirements, pagination behavior, error handling, or what the output looks like (e.g., format of returned papers). For a search tool with no annotation coverage, this is a significant gap.

  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 appropriately sized and front-loaded, starting with the core purpose. The second sentence elaborates on use cases efficiently. However, the phrase 'Perfect for finding research papers, scientific studies, technical papers, and academic literature' is slightly redundant with the first sentence, and it could be more structured (e.g., separating purpose from guidelines).

  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?

  Given no annotations and no output schema, the description is incomplete for a search tool with 3 parameters. It covers purpose and usage context well but lacks behavioral transparency (e.g., output format, limitations) and doesn't compensate for the missing output schema. The schema handles parameters, but overall completeness is only adequate with clear gaps.

  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 schema already documents all three parameters (query, num, tbs) with good descriptions. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter interactions, provide examples beyond those in the schema, or clarify edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 with specific verbs ('search academic papers and preprints') and resource ('arXiv repository'), distinguishing it from siblings like search_web or search_images by specifying the academic/scientific domain. It explicitly mentions what it searches for (research papers, scientific studies, etc.), making the purpose unambiguous.

  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 provides clear context for when to use this tool ('when researching scientific topics, looking for papers by specific authors, or finding the latest research in fields like AI, physics, etc.'). However, it does not explicitly state when NOT to use it or mention alternatives like parallel_search_arxiv or search_ssrn, which are relevant sibling tools for similar purposes.

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

• guess_datetime_urlA
  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 describes the analysis methods and output format (timestamp with confidence scores), adding value beyond the input schema, but doesn't cover error handling, rate limits, or performance characteristics. It's adequate but lacks depth for a complex analysis tool.

  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 appropriately sized and front-loaded, starting with the core purpose and followed by details on methods and output. Every sentence adds value, though it could be slightly more streamlined by reducing the list of methods without losing clarity.

  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?

  Given the tool's complexity (analyzing multiple data sources) and no annotations or output schema, the description is moderately complete—it explains the purpose, methods, and output format. However, it lacks details on confidence score interpretation, error cases, or limitations, leaving gaps for an AI agent to fully understand behavioral nuances.

  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%, with the single parameter 'url' well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, but the baseline is 3 since the schema adequately covers the parameter 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?

  The description clearly states the specific verb ('guess') and resource ('last updated or published datetime of a web page'), distinguishing it from sibling tools like 'read_url' or 'parallel_read_url' that fetch content rather than analyze temporal metadata. It explicitly identifies what the tool does without being tautological.

  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 implies usage context by detailing the methods used (e.g., HTTP headers, HTML metadata), suggesting it's for web page analysis, but doesn't explicitly state when to use it versus alternatives like 'read_url' for general content extraction. It provides clear intent but lacks explicit sibling differentiation or exclusion criteria.

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

• primerA
  3.8/5.0
  Behavior3/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 describes what information the tool provides (time, location, network environment) and the purpose (enabling localized, time-aware responses). However, it doesn't disclose important behavioral aspects like whether this requires user permissions, what format the information returns, whether it's cached or real-time, or any rate limits. The description adds value but leaves significant behavioral questions unanswered.

  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 perfectly concise and well-structured. Two sentences: the first states the purpose with specific examples, the second provides clear usage guidance. Every word earns its place with no redundancy or fluff. The information is front-loaded with the core purpose immediately stated.

  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?

  Given the tool's complexity (session context retrieval), lack of annotations, and no output schema, the description is moderately complete. It explains what the tool provides and when to use it, but doesn't describe the return format, data structure, or any limitations. For a context-fetching tool with no structured output documentation, the description should ideally specify what exactly gets returned (e.g., 'returns an object with time, location, and network properties').

  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?

  The tool has 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters since none exist. It appropriately focuses on what the tool does rather than parameter details. The baseline for 0 parameters is 4, and the description meets this expectation without attempting to document non-existent parameters.

  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: 'Get up-to-date contextual information of the current session to provide localized, time-aware responses.' It specifies the verb ('Get') and resource ('contextual information') with concrete examples (time, location, network environment). However, it doesn't explicitly differentiate from sibling tools, which are mostly search/processing tools unrelated to session context.

  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 provides clear usage context: 'Use this when you need to know the current time, user's location, or network environment to give more relevant and personalized information.' It gives specific scenarios for when to use the tool. However, it doesn't mention when NOT to use it or explicitly contrast with alternatives 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.

• sort_by_relevanceA
  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 explains the core functionality (reranking by relevance) and mentions the external API (Jina Reranker), but does not disclose important behavioral traits such as rate limits, authentication requirements, error handling, or what happens when documents are empty. It adds some context about use cases but lacks operational details.

  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 appropriately sized at three sentences, with the first sentence clearly stating the core functionality. Each sentence adds value: the first explains what the tool does, the second provides usage context, and the third gives application examples. There is minimal redundancy, though the second sentence could be slightly more concise.

  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?

  Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It explains the purpose and usage context well but lacks details about behavioral aspects (e.g., performance, limitations, error cases) and output format. Without annotations or an output schema, the description should provide more operational context for effective 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?

  Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain parameter interactions, default values, or constraints). The baseline score of 3 is appropriate when the schema does the heavy lifting.

  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 with specific verbs ('rerank', 'sort') and resources ('list of documents', 'documents'), explicitly mentioning the Jina Reranker API. It distinguishes this tool from sibling tools like deduplicate_strings or search_web by focusing on relevance ranking rather than deduplication or web searching.

  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 provides clear context for when to use the tool ('when you have multiple documents and want to sort them by how well they match a specific query or topic') and gives examples of use cases ('document retrieval, content filtering, or finding the most relevant information from a collection'). However, it does not explicitly state when NOT to use it or name specific alternatives among sibling tools.

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

• extract_pdfA
  3.9/5.0
  Behavior3/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 key behavioral traits: it extracts elements using layout detection, returns base64-encoded images with metadata, and handles arXiv IDs or PDF URLs. However, it lacks details on permissions, rate limits, error handling, or output structure beyond metadata mention.

  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 appropriately sized and front-loaded, with two sentences that efficiently convey purpose, context, and output. Every sentence adds value: the first defines the action and method, the second specifies use cases and return format, with zero wasted words.

  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?

  Given no annotations and no output schema, the description is moderately complete for a 4-parameter tool. It covers purpose, input sources, and output format, but lacks details on behavioral constraints, error cases, or exact metadata structure. It's adequate but has gaps in transparency for a mutation-like extraction 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%, so the schema fully documents all 4 parameters. The description adds no specific parameter semantics beyond implying the tool works with arXiv papers and PDF URLs, which is already covered in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 with specific verbs ('extract figures, tables, and equations') and resources ('PDF documents'), using layout detection. It distinguishes from sibling tools by focusing on visual element extraction from PDFs, unlike general search or read tools in the sibling list.

  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 provides clear context for when to use this tool ('Perfect for extracting visual elements from academic papers on arXiv or any PDF URL'), but does not explicitly state when not to use it or name specific alternatives from the sibling tools. It implies usage for PDFs with visual content but lacks exclusion criteria.

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

• read_urlA
  3.9/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 describes the core functionality (extracting and converting content) and mentions bypassing paywalls as a behavioral trait. However, it doesn't address important behavioral aspects like rate limits, authentication requirements, error handling, or what happens with malformed URLs.

  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 perfectly front-loaded with the core purpose in the first sentence, followed by usage context. Every sentence earns its place by providing distinct value - the first states what it does, the second gives content examples, and the third provides usage scenarios. No wasted words.

  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?

  For a tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate but incomplete context. It covers the purpose and usage well but lacks behavioral details about rate limits, authentication, error handling, and doesn't describe the output format (though no output schema exists to document this).

  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 schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

  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 with specific verbs ('extract and convert') and resources ('web page content to clean, readable markdown format'). It distinguishes from sibling tools by focusing on content extraction/conversion rather than screenshot capture, PDF extraction, or search operations.

  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 provides clear context for when to use the tool ('when you need to analyze text content from websites, bypass paywalls, or get structured data') and gives examples of appropriate content types (articles, documentation, blog posts). However, it doesn't explicitly state when NOT to use it or name specific alternatives 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.

• search_jina_blogA
  3.9/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 describes what content is searched (Jina AI news and blog posts) and the types of content returned, but doesn't mention important behavioral aspects like rate limits, authentication requirements, pagination behavior, or error conditions. The description adds value but leaves significant behavioral questions unanswered.

  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 efficiently structured in two sentences that each earn their place. The first sentence establishes the core purpose and scope, while the second provides usage context. There's no wasted verbiage or redundancy.

  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?

  For a search tool with 3 parameters, 100% schema coverage, but no output schema and no annotations, the description provides adequate purpose and usage context. However, it doesn't describe the return format, result structure, or what happens when no results are found, which would be helpful given the lack of output schema.

  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 schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

  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: searching Jina AI news and blog posts at a specific URL (jina.ai/news) for content about specified topics. It distinguishes this tool from sibling tools by focusing on Jina's official content rather than general web search or other academic/search tools.

  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 provides clear context about when to use this tool: to find official Jina documentation, tutorials, product announcements, and technical deep-dives. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for different search needs.

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

• search_webA
  4/5.0
  Behavior3/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 mentions the tool searches for 'current information' and is 'ideal for answering questions about recent events,' which implies up-to-date results, but lacks details on rate limits, authentication needs, result format, or pagination. The description adds some behavioral context but doesn't fully compensate for the absence of annotations.

  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 appropriately sized and front-loaded, starting with the core purpose. It uses two sentences efficiently, with the second sentence providing usage guidelines without redundancy. Every sentence adds value, though it could be slightly more structured for clarity.

  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?

  Given the tool's complexity (6 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose and usage well but lacks details on behavioral traits like result format, error handling, or limitations. Without annotations or output schema, more context on what to expect from results would improve completeness.

  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 schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, such as examples or usage tips. With high schema coverage, the baseline is 3, as the description doesn't enhance parameter understanding.

  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 with specific verbs ('search the entire web') and resources ('current information, news, articles, websites'). It distinguishes from siblings by specifying web search versus academic (arxiv/ssrn), image search, or URL operations, making the scope explicit.

  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 on when to use this tool ('when you need up-to-date information, want to find specific websites, research topics, or get the latest news') and includes ideal use cases ('answering questions about recent events, finding resources, or discovering relevant content'). It implicitly distinguishes from siblings by focusing on general web content versus specialized sources.

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

• search_imagesA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies the default return format ('small base64-encoded JPEG images') and the alternative behavior when return_url is true ('return image URLs, title, shapes, and other metadata'). It doesn't mention rate limits, authentication needs, or potential costs, but provides substantial operational context.

  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 appropriately sized with three sentences that each serve distinct purposes: stating the core function, providing usage context, and describing output behavior. It's front-loaded with the most important information. While efficient, the third sentence could be slightly more concise by integrating the return_url behavior more directly.

  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 tool's moderate complexity (6 parameters, 1 required), no annotations, and no output schema, the description does well to cover the essential context: purpose, usage scenarios, and output format behavior. It doesn't explain error conditions, rate limits, or authentication requirements, but provides enough information for basic effective use of this 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?

  The schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema - it mentions the default base64 encoding and that return_url changes the output format, but doesn't elaborate on other parameters like tbs, location, gl, or hl. The schema already documents these thoroughly, so the description adds limited extra value.

  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 the tool's purpose as 'Search for images across the web, similar to Google Images' with specific examples of what can be found (photos, illustrations, diagrams, charts, logos). It clearly distinguishes from sibling tools like search_web or search_arxiv by focusing exclusively on visual content, making the purpose highly specific and differentiated.

  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 provides clear context for when to use this tool: 'when you need to find photos, illustrations, diagrams, charts, logos, or any visual content' and gives examples like 'illustrate concepts, locating specific pictures, or discovering visual resources.' However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, which prevents a perfect score.

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

• search_ssrnA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It mentions the tool is 'perfect for finding research papers' and lists academic domains, but doesn't disclose behavioral traits like rate limits, authentication needs, pagination behavior, or error handling. It adds some context about the platform but lacks operational details.

  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 efficiently structured with two sentences: the first states purpose and domain, the second provides clear usage guidelines. Every sentence adds value without redundancy, making it appropriately sized and front-loaded.

  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?

  Given no annotations and no output schema, the description provides good purpose and usage context but lacks details about return values, error conditions, or operational constraints. It's adequate for a search tool but could be more complete about behavioral aspects.

  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 schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate but no extra value.

  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 specific action ('Search academic papers and preprints') and resource ('on SSRN'), distinguishing it from sibling tools like search_arxiv or search_web by specifying the academic domain focus on social sciences and related fields.

  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 explicitly states when to use this tool: 'when researching social science topics, looking for working papers, or finding the latest research in business and economics fields.' It also distinguishes from siblings by specifying the SSRN platform and academic focus.

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

• deduplicate_imagesA
  4.2/5.0
  Behavior3/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 describes the algorithm (Jina CLIP v2 embeddings and submodular optimization) and the output format (URLs or base64-encoded images), but doesn't mention performance characteristics, rate limits, error conditions, or what happens when k is not provided beyond 'automatically finds optimal k.'

  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 that efficiently convey purpose, method, and usage guidelines without any wasted words. It's appropriately sized and front-loaded with the core functionality.

  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 tool with 2 parameters, 100% schema coverage, and no output schema, the description provides good context about what the tool does and when to use it. However, without annotations or output schema, it could benefit from more behavioral details about performance, errors, or output format specifics.

  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 schema already fully documents both parameters. The description doesn't add any additional parameter semantics beyond what's in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.

  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 specific action ('Get top-k semantically unique images'), the resource (images represented as URLs or base64-encoded strings), and the method (using Jina CLIP v2 embeddings and submodular optimization). It distinguishes from sibling tools like 'deduplicate_strings' by specifying it works on images rather than text.

  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 explicitly states when to use this tool: 'when you have many visually similar images and want the most diverse subset.' This provides clear context for usage and distinguishes it from other tools that might handle different data types or purposes.

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

• deduplicate_stringsA
  4.6/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 of behavioral disclosure. It effectively describes the tool's behavior: it uses Jina embeddings and submodular optimization to select semantically unique strings, returns a subset based on diversity, and automatically determines k if not provided. However, it doesn't mention performance characteristics like speed, rate limits, or error handling, which could be useful for an agent.

  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 front-loaded with the core purpose in the first sentence, followed by usage guidelines and examples. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension by an AI agent.

  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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and behavioral aspects. However, without an output schema, it doesn't specify the return format (e.g., array of strings, scores), which is a minor gap. The description compensates well but isn't fully exhaustive.

  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?

  The schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantic processing ('using Jina embeddings and submodular optimization') and the purpose of k ('to select the most diverse subset'), which goes beyond the schema's technical definitions. It also clarifies the automatic k behavior, enhancing parameter understanding.

  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 with specific verbs ('get top-k semantically unique strings') and resources ('from a list using Jina embeddings and submodular optimization'). It distinguishes itself from siblings like 'deduplicate_images' by specifying it works on strings rather than images, and from 'sort_by_relevance' by focusing on semantic diversity rather than relevance ranking.

  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 explicitly states when to use this tool ('when you have many similar strings and want to select the most diverse subset that covers the semantic space') and provides three specific use cases ('removing duplicates, selecting representative samples, or finding diverse content'). It doesn't mention alternatives, but given the sibling tools, none directly overlap with string deduplication, making the guidance complete.

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