Server Quality Checklist

Tool Scores

• convert_currencyA
  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 the burden of disclosing behavior. It sufficiently explains the return format with a concrete example and notes that rates are live. It does not mention error behavior (e.g., invalid currency codes), but for a simple read-only conversion tool, the provided context is adequate.

  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 and well-structured: the first sentence states the purpose, and the second provides a concrete return format example. Every sentence adds value, with no wasted words.

  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?

  The tool is simple, the input schema fully documents all parameters, and an output schema exists. The description also illustrates the return structure, making the tool contextually complete for an agent to use effectively.

  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 each parameter already including a description, defaults, and examples. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool fetches live exchange rates and converts amounts, which is a specific verb+resource combination. It distinguishes the tool from sibling tools, as no other sibling handles currency conversion.

  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?

  Usage is implied by the description: it is for fetching live exchange rates and converting amounts. However, there is no explicit guidance about when to prefer this over alternatives or when not to use it, though no obvious alternative exists among siblings.

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

• search_hackernewsA
  4.2/5.0
  Behavior4/5

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

  Explicitly states 'makes no local changes' and discloses the network dependency on the Algolia HN API, plus the empty-list behavior. With no annotations present, the description carries the burden well, though it omits rate-limit or error 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?

  Two sentences, front-loaded with the main action and output shape, and no redundant phrasing. Every sentence contributes meaningful information.

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

  Completeness4/5

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

  For a simple search tool with a rich schema and explicit output shape, the description covers the essentials: network usage, non-destructive behavior, and empty-list handling. It could mention rate limits or errors, but that is not critical given the simplicity.

  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 every parameter having type, default, and example. The description adds no parameter-specific details beyond the schema, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  Description opens with a specific verb 'Search' and resource 'Hacker News stories', and clearly specifies the output as a list of dicts with named fields (title, url, points, author, num_comments). This clearly distinguishes it from sibling search tools like search_github or search_images.

  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?

  States it queries the public Hacker News index over the network and returns an empty list for no matches/empty query, providing clear usage context. It does not explicitly mention alternatives or exclusions, but the tool's niche is unambiguous given the sibling list.

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

• search_ikeaA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that results require network access, reflect live listings, prices/currency vary by country/language, and returns an empty list on no matches. This adds meaningful behavioral context beyond the schema, though it doesn't cover potential errors or rate limits.

  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, front-loaded with the core purpose, followed by behavioral details and edge cases. Every sentence adds value with no fluff or redundancy.

  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 (4 params, scrape-based behavior, output schema exists), the description covers purpose, return format, network dependence, and empty-result behavior. It doesn't mention potential scraper brittleness or error cases, but the schema and output schema fill most gaps, making it largely complete.

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

  Parameters3/5

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

  The input schema has 100% coverage with detailed descriptions for each parameter. The description adds a bit of context (e.g., tying lang/country to live listings) but largely restates what the schema already conveys, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states the tool 'Search IKEA's online catalog for furniture and home products' with a specific verb and resource, and mentions returning product dicts with fields. This clearly distinguishes it from sibling tools like search_amazon or search_newegg by focusing on IKEA.

  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 on usage: it scrapes IKEA's live website, requires network access, and is per-country/language. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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

• get_ubereats_menuA
  4.3/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and succeeds: it reveals that the tool scrapes live network data at call time, requires internet access, depends on store location/hours, and returns an empty result rather than an error for invalid/unavailable/empty menus. These are crucial behavioral traits that go beyond the schema.

  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 dense sentences, each earning its place: the first states purpose and output, the second explains live scraping behavior, and the third covers edge cases. It is front-loaded with the primary action and contains no filler.

  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 simple single-parameter interface, the presence of an output schema, and no annotations, the description covers all necessary context: what it returns, how it behaves at runtime, and failure modes. It is complete enough for an agent to select and invoke the tool correctly.

  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 parameter store_url is fully documented in the schema, including its source (search_ubereats result) and an example. Since schema description coverage is 100%, the baseline is 3, and the main description adds no additional parameter-level semantics beyond what the schema already provides.

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

  Purpose5/5

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

  The description opens with a specific verb ('Fetch') and resource ('an Uber Eats restaurant's live menu from its store URL'), immediately distinguishing it from generic scrapers like scrape_url and from search_ubereats. It also specifies the key output fields (names, descriptions, prices), leaving no ambiguity about what the tool does.

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

  Usage Guidelines3/5

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

  The description implies the tool is for store URLs (especially from search_ubereats, as noted in the schema) but does not explicitly state when to use it over sibling tools like scrape_with or scrape_url. It gives context about needing a valid store URL and network access but stops short of clear when-to-use/when-not-to-use guidance.

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

• scrape_stockA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It thoroughly discloses return shapes for each mode, which is the primary behavioral aspect. It doesn't mention rate limits or error handling, but the read-only nature is implied by 'fetch' and the output specification is detailed.

  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 well-structured and front-loaded with the main action. It efficiently uses a list format to convey return keys, and every sentence serves a purpose without 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?

  Given the output schema exists and the description explicitly defines the return dict for all three modes, the description is comprehensive. Parameter schema is also thorough, so no critical gaps remain.

  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 already has 100% coverage with detailed descriptions for each parameter. The description adds value by explaining how mode affects the output shape, but this is a logical inference rather than new parameter semantics. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb 'fetch' and the resource 'stock market data from Yahoo Finance', and specifies the return type as a dict. It also distinguishes this tool from siblings like scrape_url and get_crypto by focusing on stocks from a specific source.

  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: it is for fetching stock data from Yahoo Finance. It doesn't explicitly mention alternatives or when not to use it, but the domain is specific enough for an agent to infer appropriate use.

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

• scrape_zomatoA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states network access ('Requires outbound network access'), live data variability ('results reflect live Zomato data at call time and may vary between calls'), and edge-case behavior ('Returns an empty list if the city is unknown'). It does not mention rate limits or potential blocking, but the disclosed behavior is substantial and helpful 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 concise, front-loaded with the core purpose, and every sentence adds value. It covers purpose, method, filters, output format, ordering, caps, edge cases, and network dependency without unnecessary fluff. It is well-structured and easy to parse.

  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?

  The description provides a complete picture for a scraped-list tool: it states what it does, how it works (network scraping), what output to expect (dict list with example fields, ordering), how to control result count (max_results), and failure modes (unknown city, no matches). Given 3 parameters and no output schema shown, this is sufficiently thorough for an agent to invoke correctly.

  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%, so the baseline is 3. The description adds meaningful context beyond the schema: query is described as 'a cuisine or name term' and max_results is described as capping the list. It also clarifies the output structure (list of dicts with example fields), which indirectly informs parameter meaning. This exceeds 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?

  The description clearly states the tool's function: 'Search Zomato for restaurants in a city and return a list of restaurant records.' It uses a specific verb (search/scrape) with a specific resource (Zomato restaurants) and highlights distinct features like city-based search and optional filters. This distinguishes it from sibling tools such as scrape_url or search_ubereats.

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

  Usage Guidelines3/5

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

  The description implies usage context ('Search Zomato for restaurants in a city') but does not explicitly mention when to use this tool versus alternatives or provide exclusion criteria. It lacks statements like 'for restaurant listings from Zomato, use this' or 'not for other food delivery services.' No alternatives are referenced, so guidance is only implied.

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

• search_imagesA
  4.3/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, and it delivers. It reveals the exact result structure, notes engine-specific field availability (e.g., Google path fills only a subset), and states that results are in engine relevance order. This goes beyond basic expectations, though it does not cover error handling or rate limits.

  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, front-loaded with the primary action, and every sentence adds value. It efficiently packs important behavioral details (result keys, engine variations, empty field conventions) without verbosity or repetition of schema content.

  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 simplicity (3 params, one required), an existing output schema, and clear return-value documentation in the description, the contextual information is complete. It covers what the tool does, what results look like, how engines differ, and the ordering, leaving minimal room for ambiguity.

  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 already provides detailed descriptions and defaults for all three parameters (query, engine, max_images), achieving 100% schema description coverage. The tool description adds no additional parameter-specific semantics, but the schema alone is sufficient, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb ('Search') and resource ('images'), clearly distinguishing it from sibling tools like search_youtube or search_books. It explicitly states it returns a list of result objects with image URLs and metadata, making the tool's function unmistakable.

  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 clearly implies when to use this tool (when you need images from the web) and the context is unmistakable given sibling search tools for other media types. It does not explicitly mention alternatives or exclusions, but the purpose is so concrete that no additional guidance is needed.

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

• search_linkedin_jobsA
  4.3/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 and does well: it reveals that the tool scrapes over the network (not an API), requires no login, returns a list of dicts with typical keys, returns an empty list on no matches, and that results are live and may vary between runs. This is strong transparency. It doesn't mention rate limits or error handling, but the disclosed traits are sufficient for a 4.

  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 compact and front-loaded. The first sentence states the purpose, and the second block adds essential behavioral details (no login, return format, empty-list behavior, live scraping variability). Every sentence earns its place with no fluff or repetition.

  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 scraping nature and the presence of a rich output schema, the description is complete. It covers purpose, network method, auth requirements, output structure, empty-result behavior, and data freshness. This is sufficient for an agent to decide when and how to invoke the tool without needing additional information.

  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% — every parameter (query, location, max_pages) has a clear description with examples and defaults. The tool description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate. No additional value is contributed.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Search LinkedIn public job postings and return a list of matched jobs.' It specifies the resource (LinkedIn job postings), the verb (search), and the output (list of matched jobs). This distinguishes it from sibling search tools that target other sources like GitHub, Hacker News, or books.

  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 context on when to use the tool: for scraping LinkedIn's public job search without login. It mentions network scraping and live results. However, it does not explicitly exclude alternatives or state "use this instead of X" — although sibling tools are all different sources, making the context fairly clear. The lack of explicit exclusions keeps it from a 5.

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

• search_youtubeA
  4.3/5.0
  Behavior5/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 disclosure. It explicitly states that the operation is read-only, has no side effects, performs a live network search, and results may vary between calls. It also describes the edge case of returning an empty list for no matches. This is transparent and goes beyond minimal 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?

  The description is concise and well-structured: it opens with a clear purpose, then adds behavioral context, then describes the return format, and finally addresses an edge case. Every sentence contributes useful information without redundancy or unnecessary length.

  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 moderate complexity, the presence of an output schema, and full parameter schema coverage, the description is remarkably complete. It explains purpose, network behavior, safety (read-only), return fields, and empty-list behavior. No critical information needed for correct invocation or interpretation is missing.

  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 already provides 100% description coverage, including examples and defaults for both 'query' and 'max_results'. The description text does not add significant parameter-specific meaning beyond referencing the query. Since the schema handles parameter semantics well, a baseline score of 3 is appropriate, and the description does not need to compensate.

  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 verb 'Search' and the resource 'YouTube', and specifies the action: searching for videos matching a query and returning metadata. This distinguishes it from sibling tools like search_images or search_github, which target different resources and use different verbs.

  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 mentions that it performs a live YouTube search over the network, providing context that results are current and non-deterministic. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or scenarios where another tool would be preferable. The usage context is implied but not fully articulated.

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

• scrape_wikipediaA
  4.4/5.0
  Behavior4/5

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

  Since annotations are absent, the description carries the full burden. It discloses that a live network request is made, explains how query resolution works, and details the return shape for each mode plus the empty-result behavior. It does not mention rate limits or error handling, but the key behaviors are clearly covered.

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

  Conciseness4/5

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

  The description is concise but not overly terse. The first sentence immediately states the purpose, and the second paragraph adds behavioral detail in a structured way. Every sentence contributes value, though the content could be slightly tightened.

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

  Completeness4/5

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

  The description covers the core behavior, return shapes, and empty results, which is appropriate given that an output schema exists. It does not describe error handling or network failure scenarios, but for a scraper with clear modes, this is sufficient.

  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 description adds substantial meaning beyond the schema: it defines what 'full', 'paragraphs', and 'headers' return, and explains the empty-result behavior per mode. The schema itself only lists the mode as 'one of...' without these details, so the description elevates semantic clarity.

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

  Purpose5/5

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

  The description opens with a specific verb (Fetch), a specific resource (Wikipedia article), and the action's outcome (return its text content). It clearly distinguishes from sibling tools like scrape_url or scrape_news by being exclusively about Wikipedia.

  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 clearly implies this tool is for Wikipedia content retrieval, which differentiates it from generic URL scrapers and other domain-specific scrapers. However, it does not explicitly list when not to use it or mention alternative tools, so it misses the highest bar.

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

• define_wordA
  4.5/5.0
  Behavior5/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 explicitly states network requirements, read-only semantics with no side effects, and not-found behavior (returns empty/not-found rather than raising). Additionally, it outlines the return structure, providing comprehensive transparency for a simple 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 and well-structured: the first sentence states the core purpose, followed by a second paragraph adding essential behavioral context (network, read-only, error handling) and a third describing the return format. Every sentence earns its place without unnecessary verbosity.

  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 low complexity (one parameter) and the presence of an output schema, the description is complete. It covers the tool's network dependency, safety profile, error behavior, and output structure. This is sufficient for an agent to select and invoke the tool correctly without ambiguity.

  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% coverage for the single parameter 'word', with a detailed description including examples and constraints. The main description does not add additional parameter meaning, but the baseline is 3 due to high schema coverage, and the description does not contradict or fail to compensate.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Look up an English word and return its dictionary entry.' It specifies the resource (English words) and the output (definitions, parts of speech, example sentences), which distinguishes it from sibling tools that focus on scraping or searching other domains.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool (when needing a dictionary definition) and implicitly differentiates from siblings by focusing on word lookups. It does not explicitly list alternatives or exclusions, but the parameter description adds guidance (single words only, not phrases or non-English terms), which helps usage decisions.

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

• get_cryptoA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description takes on full responsibility for behavioral disclosure. It states network dependency, confirms no local read/write, and specifies non-error behavior for empty results. These are meaningful, beyond-schema insights that help an agent anticipate side effects and edge cases.

  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 compact and well-structured. The first sentence states the core purpose and return format; the second sentence adds essential behavioral and edge-case information. Every sentence earns its place, with 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?

  Despite having no annotations, the combination of a complete schema, an output schema (indicated by context), and a description that covers purpose, network behavior, result format, and edge cases makes this fully adequate for an agent to select and invoke the tool correctly. No significant gaps remain.

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

  Parameters3/5

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

  Schema description coverage is 100%: all three parameters (query, max_results, vs_currency) have detailed, self-explanatory descriptions including defaults and examples. The tool description repeats some of this (e.g., query omitted returns top coins) but adds minimal new parameter-level semantics. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description begins with a specific verb and resource: 'Fetch live cryptocurrency market data' and then enumerates the exact fields returned (id, symbol, name, current price, market cap, 24h change). This clearly differentiates it from sibling tools like scrape_stock or convert_currency, which serve different financial data needs.

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

  Usage Guidelines4/5

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

  It provides clear usage context: results are live, need internet access, and no local state is affected. It also explains the behavior when query is omitted (top coins) and when no matches are found (empty list, not an error). It does not explicitly name alternatives or exclusions, but the use case is unambiguous enough for an agent to decide when to invoke it.

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

• get_weatherA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the behavioral burden. It discloses that each call makes a live network request, returns a specific structured dict, and handles unresolved locations by returning an empty result or error field instead of raising. This exceeds the transparency expected for a simple 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 two sentences: the first front-loads the purpose and return format, the second adds behavioral notes. Every sentence earns its place, with no filler or redundancy. The structure is clean and scannable.

  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 one-parameter tool with an output schema, the description is remarkably complete. It specifies the exact return keys with types, explains side effects (network call, internet), and documents error behavior. The presence of an output schema does not reduce the need for description, and this description goes beyond minimum requirements.

  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% for the only parameter 'location', which includes a detailed description and example. The description's reference to a 'named place' adds no new semantic value beyond what the schema already provides. Based on the high coverage rule, a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Fetch') and clear resource ('current weather conditions for a named place'), and explicitly defines the return dict with key types, making it distinguishable from sibling tools like scrape_url or get_crypto. It is not a tautology and provides substantive detail.

  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 when to use the tool (when real-time weather is needed) and provides important context (live network call, requires internet, returns empty on unresolved location). While it does not explicitly name alternatives or exclusion criteria, the clear context and absence of a weather-like sibling make the usage unambiguous.

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

• scrape_newsA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses that content is fetched live over the network, results are not cached, and an empty list is returned on no results or feed parse failure. This covers key behavioral traits, though it does not mention potential timeouts, rate limits, or detailed error handling.

  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, with no redundant information. It front-loads the core function in the first sentence, then adds critical usage constraints and behavioral notes in a compact second paragraph. Every sentence earns its place.

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

  Completeness4/5

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

  Given the tool's moderate complexity and the presence of an output schema, the description adequately covers return shape, parameter relationships, and edge cases like empty results and feed discovery failure. It is complete enough for an agent to select and invoke the tool, though it omits minor aspects like network error handling or auth requirements.

  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?

  Although the schema already describes each parameter with examples, the description adds crucial semantics: the mutual exclusivity of feed_url, site_url, and article_url, and the differing return counts (one vs. up to max_articles). This goes beyond the schema and significantly aids correct invocation.

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

  Purpose5/5

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

  The description clearly states the tool's function: fetching news articles from RSS/Atom feeds, news sites with auto-discovery, or single articles, and returning article dicts. It uses specific verbs and resources, and the mention of news articles distinguishes it from generic scrapers like scrape_url.

  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: 'Provide exactly one of feed_url, site_url, or article_url' and explains that article_url returns one article while feed_url/site_url return up to max_articles. However, it does not explicitly mention when to prefer this tool over sibling tools or any exclusions, so it stops short of full alternative guidance.

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

• scrape_urlA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and delivers: it discloses network fetching, that no data is stored or mutated, the plain-HTTP limitation with JS pages, the render_js=true retry path, and that failures return empty data/errors instead of raising. This is exemplary.

  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 well-structured: the first sentence front-loads the purpose and result shape, followed by useful behavioral details. Every sentence earns its place, and there is 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?

  Given an output schema exists and annotations are absent, the description covers result structure, failure handling, JS-rendering behavior, and installation note. It is complete enough for an agent to select and invoke the tool correctly.

  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 four parameters. The description adds some context about render_js and error behavior, but it does not substantially enrich parameter meaning beyond what the schema provides; baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it scrapes any HTTP(S) URL and returns a ScrapeToolResult with extracted text, links, images, tables, and metadata. The 'any URL' framing distinguishes it from specialized sibling scrapers like scrape_wikipedia or scrape_stock.

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

  Usage Guidelines4/5

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

  The description gives clear context: it works for any HTTP(S) URL and provides a specific retry instruction when JavaScript-rendered pages return empty. It does not explicitly name alternatives or exclusions, but the general-purpose wording makes the use case obvious.

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

• search_amazonA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description fully covers behavioral traits: it discloses no side effects ('no side effects beyond outgoing HTTP requests'), no auth requirements, network dependence, anti-bot throttling, and return behavior including empty list on block/no results. It also specifies the exact return shape and how missing fields are represented (empty strings or None). This is exceptionally 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?

  The description is four sentences, each earning its place: purpose, operational context, return format, and failure behavior. It is front-loaded with the essential purpose, then adds necessary behavioral caveats, and ends with the output contract. No wasted words or repetition of schema content.

  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?

  The tool is moderately complex (live network scrape with variable results), and the description covers everything an agent needs to decide and execute: live scrape, no auth, no side effects, variability, exact return schema, empty list behavior, and blocking. The presence of the output shape in the description compensates for the lack of an explicit output schema in context. Completeness is high.

  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%, and the schema already clearly documents both parameters (query and max_pages) with examples and defaults. The description itself does not add parameter-level meaning, but the schema does the heavy lifting. Per the rubric, a baseline of 3 is appropriate when schema coverage is high and no further param details are needed.

  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 opens with a specific verb and resource: 'Scrape Amazon search results for a query and return a list of matching products.' This clearly distinguishes the tool from its siblings (e.g., search_images, search_youtube) by naming Amazon as the target and defining the output. The scope is explicit and 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 usage context: it is a live network scrape of Amazon's public search pages with no login/API key, and mentions that results vary by region/availability and may be affected by throttling. It implies when to use the tool (Amazon product searches) but does not explicitly name alternatives or state when not to use it. This qualifies as clear context without exclusions, matching a 4.

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

• search_booksA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses read-only behavior, no file/state modification, network access, return format, and empty-list behavior. This is excellent 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?

  Concise and front-loaded. The first sentence captures purpose, subsequent sentences add valuable behavioral details without redundancy. Every sentence earns its place.

  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?

  Covers purpose, network/auth requirements, return shape, empty results, and side effects. Output schema exists, but the description enriches context further. Complete for a search tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, fully explaining query and max_results. The description adds no new param semantics beyond aligning with the search scope. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool searches books by title, author, or free text via the Open Library API, with a specific verb and resource. This distinguishes it from sibling search/scrape 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?

  It provides clear context: network-based, no authentication required. It does not explicitly exclude alternatives, but the book-specific scope implies when to use. No explicit when-not or alternative tool references.

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

• search_githubA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It discloses the return format (list of dicts with specific keys), ordering behavior (per sort argument), empty-list behavior when no matches, network access requirement, and rate limits. This is thorough and directly useful to 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 four sentences, front-loaded with the primary purpose, and every sentence adds value: scope, network behavior, return structure, empty-list handling, and rate-limit warning. No redundant or filler text.

  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?

  The description is complete for this tool's complexity. It explains inputs, output schema, network dependency, rate limits, and edge-case behavior (empty list). Combined with a well-described input schema, an agent has enough information to invoke it correctly without ambiguity.

  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 already has 100% coverage with detailed descriptions and examples for all three parameters, so the baseline is 3. The description adds little beyond mentioning ordering by sort, which the schema already covers. It does not need to compensate since the schema is sufficient.

  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 a specific verb ('Search') and resource ('GitHub for public repositories'), and the return type is described as a list of repository records. This distinguishes it from sibling search tools like search_images or search_hackernews, which target different domains.

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

  Usage Guidelines4/5

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

  The description provides clear context: it queries the GitHub search API over the network, requires network access, and may hit GitHub API rate limits. It does not explicitly name alternatives or exclusions, but the scope ('GitHub for public repositories') makes the intended use unambiguous.

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

• search_neweggA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full responsibility and does an excellent job. It discloses live scraping, outbound network access, the return of an empty list on failure, and explicitly labels the operation as read-only with no side effects beyond HTTP requests. This goes well beyond a basic statement of purpose.

  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 compact and front-loaded. The first sentence states purpose and output, the second adds essential behavioral caveats. Every sentence contributes meaningful information with 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?

  The tool has an output schema and full parameter schema coverage, so the description need not repeat field details. It adds critical context about network dependency, failure modes, and side effects, making the description complete enough for an agent to use effectively.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides; the schema itself fully explains query and max_pages meaning and defaults.

  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 specifies the action ('Search Newegg'), the domain ('electronics and computer hardware'), and the output shape (list of product dicts with fields). It distinguishes from siblings like search_amazon and search_ikea by naming the specific retailer and product scope.

  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 sets clear context for when to use the tool: searching Newegg. It mentions the requirement for outbound internet access and the fallback behavior (empty list on no match), which implies constraints. However, it does not explicitly contrast with alternative search tools or state when not to use it.

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

• search_soundcloudA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses key behaviors: browser backend, dependency, headless browser per call, performance trade-offs, no auth required, and empty-list behavior. This exceeds expected 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 concise and well-structured: first sentence states purpose and output, second sentence explains technical trade-offs. Every sentence earns its place with no redundancy or verbosity.

  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 modest complexity (2 params, no annotations, output schema exists), the description comprehensively covers return format, error case (empty list), dependencies, and performance caveats. It is complete for an agent to select and invoke correctly.

  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% for both query and max_results, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema provides; it focuses on output and operational context.

  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 states the specific action (search SoundCloud for tracks), the resource (SoundCloud), and the output format (list of track dicts with keys and types). This clearly distinguishes it from sibling search tools like search_youtube or search_images.

  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 contextual guidance by noting it is slower and heavier than HTTP-based tools and requires the pyscrappy[browser] extra. This implies when to use it (when SoundCloud-specific data is needed) but does not name explicit alternatives or exclusions.

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

• lookup_movieA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description discloses network reads, no browser/write/cache, OMDb API key requirement, error response when key is missing, and empty-result behavior on no match.

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

  Conciseness5/5

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

  Two dense sentences front-load the purpose and then add essential operational detail; no filler.

  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?

  The description covers return shapes for both lookup modes, authentication, network behavior, and edge cases, making it complete for the tool's complexity and existing output schema.

  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 clear parameter descriptions; the description further explains that 'query' can be a title or tt-id and that 'max_pages' only applies to title searches, adding semantics 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 opens with a specific verb ('look up') and resource (movie and TV data from IMDB via OMDb API), and explains both title-search and IMDB-id lookup modes, distinguishing it from scraping siblings.

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

  Usage Guidelines4/5

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

  It clearly defines the context (movie/TV lookups) and explains the two query types, but does not explicitly name alternative tools or state when not to use it.

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

• scrape_withA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and does so thoroughly: it reveals that args are forwarded to scrape(), return shape is scraper-specific, side effects (network, auth, browser rendering) vary by target, unknown names throw an error, and empty results return the scraper's empty structure. This comprehensively sets 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?

  The description is front-loaded with the core action and uses four additional sentences that each earn their place: dispatch logic, return shape, side-effect caveat, and error/empty behavior. No filler or repetition.

  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 generic dispatcher with 2 params and an output schema, the description is complete. It explains the dispatch mechanism, return variability, side effects, failures, and empty results—without needing to describe return values in detail since an output schema exists.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description adds no significant meaning beyond the schema: 'name' is the registry name, 'args' are forwarded to scrape(). The schema already states both, so the description provides minimal added 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 opens with a specific verb+resource: 'Run any registered scraper... by name and return that scraper's raw scrape() output.' It clearly distinguishes this generic dispatcher from the sibling-specific scrapers and list_available_scrapers by framing it as the entry point for scrapers lacking a dedicated tool.

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

  Usage Guidelines5/5

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

  Explicitly states when to use: 'This is the generic dispatch entry point for scrapers that lack a dedicated tool, notably third-party plugins.' This implies the when-not-to-use (use dedicated tools when available) and describes the alternative conceptual category, giving clear context.

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

• search_ubereatsA
  4.7/5.0
  Behavior5/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 so excellently. It discloses network fetching at call time, lack of API key, the data cap via max_results, the envelope structure, non-fatal errors, and empty-list behavior for unrecognized cities or no results. This goes beyond just stating the operation.

  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 well-structured into two clear sentences/paragraphs. The first sentence delivers the core purpose, followed by essential operational details. Every sentence provides necessary information without redundancy, making it appropriately concise.

  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?

  The description covers the return envelope, count/scraper/source_urls/errors fields, error handling, empty results, network implications, and the link to get_ubereats_menu. Given the output schema exists, it still explains the envelope structure adequately, leaving no major gaps for the agent to select and invoke the 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 coverage is 100% with both parameters already described. The description adds extra meaning by explaining that max_results caps the data list and that city is required for the search. It reinforces the purpose of each parameter in the broader workflow, adding 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?

  The description clearly states the tool's verb and resource: 'Search Uber Eats for restaurants delivering in a given city'. It distinguishes itself by specifying the output envelope and the relationship to get_ubereats_menu, making it unique among siblings.

  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 that this is a live network search with no API key, and explicitly mentions the store URL is the input for get_ubereats_menu, indicating a complementary workflow. It lacks explicit 'when not to use' or alternative tool comparisons, but the usage context is clear.

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

• list_available_scrapersA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: it reads the in-process registry, covers built-ins and self-registering third-party plugins, performs no network/browser access, changes no state, and returns an empty list when none are registered. This is exemplary transparency for a read-only discovery 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 well-structured and front-loaded with the core purpose, followed by implementation detail, safety guarantees, return format, and usage guidance. Every sentence contributes meaningful information without 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?

  Given zero parameters and no annotations, the description covers all necessary context: what the tool does, how it works, side effects (none), return value, examples, and workflow integration with scrape_with. It is fully self-sufficient for an agent to select and invoke the tool correctly.

  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 zero parameters, so there is nothing for the description to explain beyond the schema. The description instead adds value by clarifying return semantics (list of strings, example values, empty-list behavior), which is appropriate and supports a baseline-above score.

  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 opens with 'List every scraper registered with this server and return their names for use with scrape_with,' which uses a specific verb and resource, clearly distinguishing this discovery tool from scraping/sibling tools. The scope ('registered with this server') and the complementary reference to scrape_with make 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 Guidelines5/5

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

  The 'Usage Guidelines' section explicitly instructs calling this tool first, passing returned names to scrape_with, and using it to confirm plugin registration. This provides clear when-to-use guidance and a direct workflow with its primary sibling tool.

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