enterprise-mcp-gateway

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds return field context but does not disclose rate limits, authentication, ordering, or pagination. Adequate but not enriched beyond annotations.

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

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

Very concise: one-line purpose, two-line parameter docs. Front-loaded with category and action. No redundant sentences. Efficient for agent consumption.

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

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

For a simple search tool, the description covers basic usage. However, it lacks pagination details, result ordering, and any advanced query syntax. Adequate but not comprehensive.

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

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

Schema is bare (no descriptions), so the description fills the gap with example queries and default value for max_results. This adds significant meaning beyond the schema types and required flag.

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

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

Description clearly states verb ('Search'), resource ('arXiv'), and domain ('academic papers'). It distinguishes from siblings like 'search_google_scholar' and other search tools. The return contents are listed, leaving no ambiguity.

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

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

No explicit when-to-use or when-not-to-use guidance. The category prefix implies academic use, but alternatives like 'google_scholar' exist without explanation of trade-offs. Usage is implied but not contrasted.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds that it returns titles, authors, citations, and links, which gives some insight into the output but does not disclose other behavioral traits such as pagination, rate limits, or authentication needs. The description does not contradict annotations.

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

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

The description is extremely concise and front-loaded. It starts with a clear purpose and then lists parameter definitions in a structured docstring format. Every sentence is necessary and there is no wasted text.

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

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

Given the tool has no output schema, the description partially explains the return format (titles, authors, citations, links). It does not provide details on structure or pagination, but it is adequate for a simple search tool. Annotations compensate for safety context. Sibling differentiation is missing, but the description is otherwise complete enough.

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

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

Schema description coverage is 0%, so the description carries the burden. It provides clear descriptions for both parameters: 'query' with an example and 'max_results' with its default value. This adds significant meaning beyond the bare schema, compensating well for the low coverage.

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

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

The description clearly states it searches Google Scholar for academic papers and returns titles, authors, citations, and links. The purpose is clear, but it does not differentiate from the sibling tool 'developer-tools__search_google_scholar' which likely performs the same function.

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

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

No explicit guidance on when to use this tool over alternatives. The description does not mention when to prefer this over sibling tools like 'academic-research__search_arxiv' or 'developer-tools__search_google_scholar'. Implied usage is for academic research, but no exclusions or alternatives are provided.

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

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

Annotations already indicate readOnlyHint and openWorldHint, so the description's addition of 'Returns price ranges and dealer inventory' is useful but minimal. It does not elaborate on behavioral traits such as geographic scope, data freshness, or any limitations, but there is no contradiction with annotations.

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

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

The description is extremely concise: two sentences plus an arg list. It is front-loaded with the purpose and avoids any extraneous information. Every sentence earns its place.

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

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

Given the tool's simplicity, the description covers the basics but lacks details about the output (e.g., format, structure) and any assumptions (e.g., region, pricing basis). With no output schema, more detail would be beneficial for complete understanding.

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

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

With 0% schema description coverage, the description compensates well by explaining each parameter with examples (make, model, year) and clarifying that year is optional with default 0 meaning all years. This adds meaning beyond the bare schema types.

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

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

The description states it analyzes car market prices for a specific make/model and returns price ranges and dealer inventory. It is clear about the verb and resource. However, it does not fully distinguish from the sibling 'automotive__search_cars', which might have overlapping functionality, so clarity is slightly diminished.

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

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

The description does not provide guidance on when to use this tool versus alternatives like 'automotive__search_cars' or other market analysis tools. It lacks any explicit 'when-to-use' or 'when-not-to-use' information, making it harder for an agent to decide between tools.

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

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

Annotations already declare readOnlyHint: true and openWorldHint: true, so the agent knows it's safe and results vary. Description adds that it returns prices, mileage, dealer info, but does not disclose additional behavioral traits like rate limits or pagination.

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

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

Description is concise and front-loaded with purpose, followed by a well-structured Args section. 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.

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

Description covers return values (prices, mileage, dealer info) but lacks details on output structure, pagination, or sorting. Given no output schema, it provides a basic overview but could be more complete.

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

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

Schema description coverage is 0%, but the description compensates fully by providing clear explanations and examples for each parameter: make ('Toyota'), model ('Camry'), zip_code (ZIP code for local results), max_results (default 20). This adds significant meaning beyond the schema.

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

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

Description clearly states it searches Cars.com for vehicle listings and returns prices, mileage, dealer info. The verb 'search' and resource 'Cars.com vehicle listings' are specific, and it distinguishes from sibling tool 'automotive__car_market_analysis' which is for market analysis.

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

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

Description implies usage for searching cars via Args, but does not explicitly state when to use this tool vs alternatives or provide when-not-to-use guidance. Sibling tools like automotive__car_market_analysis offer different functionality, but no comparison is made.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds the data source (CoinGecko) but does not disclose other behavioral traits like data freshness, rate limits, or what 'market data' includes. It adds marginal value beyond annotations.

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

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

The description is concise with a clear purpose sentence followed by parameter details. It is front-loaded and avoids fluff, though the args block could be more structured.

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

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

Given the lack of output schema, the description does not explain the return format or what 'market data' includes. It is adequate for a simple read tool but misses completeness for robust agent usage.

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

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

Schema description coverage is 0%, yet the description fully explains both parameters: 'coins' (list of coin IDs, empty for top coins) and 'max_results' (max results with default 50). This adds significant meaning beyond the raw schema.

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

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

The description clearly states it gets current cryptocurrency prices and market data from CoinGecko, with a specific verb and resource. However, it does not distinguish from the sibling tool 'finance__get_crypto_prices' which likely has the same purpose.

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

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

The description provides parameter details but no guidance on when to use this tool versus alternatives like finance__get_crypto_prices or crypto__exchange_rates. There is no when-not-to-use or context for selection.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds no further behavioral details (e.g., whether rates are real-time, supported currencies, data source). It doesn't contradict annotations but provides minimal additional value.

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

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

The description is extremely concise: one sentence and an args list. Every word serves a purpose, and the key information is front-loaded. No wasted content.

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

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

Given the availability of similar tools and the lack of an output schema, the description is insufficient. It does not clarify the scope (crypto vs fiat), the format of returned rates, or any limitations. Annotations partially compensate, but more context is needed for informed use.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the single parameter 'base_currency' as a currency code with default 'USD', which adds some meaning beyond the schema. However, it does not specify allowed values or format, leaving ambiguity.

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

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

The description states 'Get current currency exchange rates' which clearly indicates the tool's purpose. However, it does not differentiate from sibling tool 'finance__get_exchange_rates' or clarify that it specifically provides crypto exchange rates, despite the tool name and annotation title suggesting a crypto focus.

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

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

No guidance is provided on when to use this tool versus alternatives like 'crypto__crypto_prices' or 'finance__get_exchange_rates'. The description lacks any contextual cues for tool selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that it returns stats like stars, forks, issues, language, description, and recent activity, which aligns with read-only behavior. However, it doesn't detail rate limits or authentication needs.

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

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

The description is concise with two sentences for purpose and a brief argument explanation. It is front-loaded with key information and has no redundant content.

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

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

With no output schema, the description lists some output fields but is vague about 'recent activity' and does not specify if the output includes all data or pagination. It covers the essentials but could be more complete.

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

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

Schema coverage is 0% with no description for the 'repo' parameter. The description fully explains the expected format ('owner/repo') and provides examples, adding essential meaning beyond the schema's type-only definition.

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

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

The description clearly states it gets GitHub repository stats and lists specific metrics (stars, forks, issues, language, description, recent activity). It distinguishes from search tools but does not differentiate from the sibling 'github__get_repo_stats', leaving ambiguity.

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

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

No guidance on when to use this tool versus alternatives like github__get_repo_stats or search_github. The description implies it for specific repo stats but lacks explicit context or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Get npm package details' aligns. However, the description adds no further behavioral context (e.g., error handling, rate limits, or missing package behavior).

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

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

Extremely concise: two sentences. The first sentence states the purpose, the second explains the argument with examples. No wasted words, and the structure is clear.

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

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

For a simple tool with one required parameter, the description covers the output fields and parameter usage. No output schema exists, but the description lists return details. Minor omissions like error scenarios or timeout expectations do not detract significantly.

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

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

The schema has 0% description coverage for the single parameter, but the description provides concrete examples ('react', 'express', 'lodash') and clarifies the parameter's role. This compensates for the schema gap, though it could specify format constraints.

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

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

Description clearly states 'Get npm package details' and lists specific data fields (version, downloads, dependencies, description, maintainers). The tool name and context distinguish it from siblings like get_pypi_package or get_github_repo.

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

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

No explicit statement about when to use this tool versus alternatives. The 'Developer Tools' category and the package name imply npm, but there is no guidance on when not to use it or what distinguishes it from PyPI or GitHub tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Beyond that, the description adds what data is returned (version, downloads, dependencies, description), providing useful behavioral context without contradicting annotations.

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

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

The description is concise with a clear purpose statement and structured Args section. It avoids fluff but could be slightly more compact by integrating the parameter description inline.

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

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

Given no output schema, the description lists the return fields (version, downloads, dependencies, description), which is sufficient for this simple lookup. It does not explain the structure or pagination, but that is likely not needed.

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

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

Schema coverage is 0%—the schema has no description for package_name. The description includes an Args section explaining 'PyPI package name' with examples, fully compensating for the missing schema descriptions.

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

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

The description specifies 'Get Python package details from PyPI' with concrete details like version, downloads, dependencies, and description. It clearly distinguishes from sibling tools like get_npm_package by focusing on Python/PyPI.

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

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

The description provides examples (e.g., 'requests', 'pandas') but does not explicitly state when to use this tool vs alternatives or any prerequisites. Usage is implied by the tool name and context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context about the fields (CS, ML, AI, physics, math) but doesn't disclose additional behavioral traits like rate limits or result format.

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

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

The description is concise: a brief sentence summarizing the tool, followed by a structured Args list. Every sentence adds value, and the format is scannable.

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

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

For a 2-parameter search tool with readOnlyHint, the description covers the essentials: what it searches, the parameters. It does not explain the output format, but this is acceptable since there is no output schema and search results are typically lists of papers.

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

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

The input schema has no descriptions for parameters (0% coverage), but the description provides a clear Args section explaining 'query' (e.g. 'large language models') and 'max_results' (default 10), adding full meaning beyond the schema.

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

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

The description clearly states 'Search arXiv for academic papers in CS, ML, AI, physics, and math.' This is a specific verb-resource combination and distinguishes it from sibling tools like academic-research__search_google_scholar or developer-tools__search_github.

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

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

No explicit guidance on when to use this tool vs alternatives. While it's clear what it does, there is no mention of when to prefer it over, for example, academic-research__search_arxiv or 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.

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

Annotations already declare readOnlyHint=true, so no behavioral contradiction. The description adds that it returns repo details (stars, descriptions, languages), but does not disclose rate limits, authentication, or pagination behavior.

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

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

Very concise: one-line summary followed by a bulleted Args section. Every sentence adds value, no wasted words.

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

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

Covers the essential purpose, return value, and parameter details. Could mention limits (e.g., max 10 results by default) or result format, but overall adequate for a simple search tool with readOnlyHint.

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

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

Schema description coverage is 0%, but the description compensates with clear parameter explanations, including an example query and the default value for max_results. This adds meaning beyond the schema's type-only definitions.

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

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

Clearly states it searches GitHub repositories by keyword and returns repos with stars, descriptions, and languages. However, it does not distinguish from the sibling tool 'github__search_repos', which likely has similar functionality.

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

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

Provides example queries in the Args section, which implies usage context, but does not explicitly state when to use this tool versus alternatives like 'github__search_repos' or other search tools in the developer-tools group.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds no behavioral details such as result format, pagination, rate limits, or authentication requirements.

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

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

Short and front-loaded with purpose, then lists arguments. The '[Developer Tools]' prefix is redundant. Could be more structured with explicit sections but is efficient overall.

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

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

For a simple search tool with annotations, the description is minimal. It lacks differentiation from the academic-research sibling, omits result format, and does not explain implications of openWorldHint. Important context missing.

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

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

Schema has 0% description coverage. Description adds examples for query and explains max_results default, providing some meaning beyond schema. However, no constraints like allowed characters or maximum length are given.

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

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

The description clearly states it searches Google Scholar for academic papers, citations, and research, with query examples. However, it does not distinguish from the identical sibling tool 'academic-research__search_google_scholar', creating potential confusion.

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

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

No guidance on when to use this tool versus alternatives like search_arxiv or the academic-research sibling. Only provides example queries and default but no usage context or conditions.

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

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

Annotations include readOnlyHint=true and openWorldHint=true, indicating safe read operation. Description adds no further behavioral context beyond stating it's a search. No contradiction, but little extra value.

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

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

Description is short and includes a structured 'Args' section. It's front-loaded with purpose. Could be slightly more organized but is efficient overall.

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

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

No output schema, and description doesn't mention return format, pagination, limitations, or error handling. Context is insufficient for a tool that returns search results.

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

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

Schema coverage is 0%, so description must compensate. It provides example queries for 'query' and mentions default for 'max_results', but no formal description of parameter format, constraints, or expected behavior. Minimal added value.

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

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

Description clearly states 'Search StackOverflow for programming questions and answers.' The verb 'Search' and resource 'StackOverflow' are specific. Among sibling tools, this is distinct from other search tools like search_github or search_arxiv.

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

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

Provides example queries and default max_results, but no explicit guidance on when to use this tool vs alternatives. No mention of when not to use or alternative tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's additional disclosure of returned record types adds value but is not comprehensive. It does not discuss rate limits, authentication, or what happens for invalid domains, which are gaps beyond the annotation coverage.

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

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

The description is extremely concise: two sentences for purpose plus a structured arguments section. Every sentence is necessary and front-loaded. No extraneous information.

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

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

For a simple tool with one parameter and no output schema, the description covers the essentials: purpose, record types, and parameter meaning. However, it lacks guidance on error handling, output format, and edge cases. Given the simplicity, it is nearly complete but could be slightly improved with a note on invalid domains.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the domain parameter with an example ('example.com'), which adds clear meaning beyond the schema's type definition. This is sufficient for a single-parameter tool, though further details on input format (e.g., subdomains) could be provided.

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

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

The description specifies the tool's function as looking up DNS records for a domain and lists the record types (A, AAAA, MX, CNAME, TXT). This clear verb-resource pairing distinguishes it from sibling tools like whois_lookup and ssl_check, which cover different aspects of domain intelligence.

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

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

The description implies the tool should be used when DNS records are needed, but it does not provide explicit guidance on when to use it versus alternatives like whois_lookup or check_dns. No exclusions or comparison with siblings are mentioned, leaving the agent to infer usage context.

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

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

Annotations indicate readOnlyHint and openWorldHint, which the description matches by stating it returns data without side effects. It adds specific fields returned, but no additional behavioral details like errors or limits.

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

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

Two short sentences plus an argument description. Every word serves a purpose; no fluff.

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

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

For a simple single-parameter lookup with no output schema, the description covers the input and basic output. Missing details like error handling or rate limits, but the tool is straightforward enough.

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

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

The description adds an example IP and clarifies the parameter is an address, supplementing the schema's bare string type. Schema coverage is 0%, so this compensation is valuable.

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

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

The description clearly states it looks up geolocation for an IP address and returns country, city, ISP. It distinguishes from sibling domain tools like DNS lookup or WHOIS.

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

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

No explicit usage guidance is provided, but the tool's purpose is implied by the name and sibling context. It does not mention when not to use or alternatives.

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

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

Annotations already indicate readOnly and openWorld hints. The description adds value by specifying the output fields (issuer, expiry, validity). No contradictions.

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

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

The description is concise with two sentences and an Args section, all front-loaded with the purpose. No unnecessary words.

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

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

For a simple tool with one parameter and no output schema, the description covers what the tool does, what it returns, and provides an example. It is complete within its context.

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

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

The single 'domain' parameter is documented with a format example. Schema coverage is 0%, but the description compensates minimally. A 3 is appropriate for a straightforward parameter.

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

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

The description clearly states the tool checks SSL certificates for a domain and lists the return fields (issuer, expiry, validity). This effectively distinguishes it from sibling tools like whois_lookup or dns_lookup.

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

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

The description provides an example domain format but no explicit guidance on when to use this tool versus alternatives. The context is clear for SSL-related queries, but lacking exclusion criteria or comparison with siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'Returns registrar, dates, nameservers' but does not elaborate on behavioral traits like rate limits, data freshness, or idempotency beyond what annotations imply.

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

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

Two sentences: first defines the tool's purpose and outputs, second defines the parameter. No unnecessary words. Front-loaded with key information.

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

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

Given one simple parameter, no output schema, and annotations present, the description sufficiently covers what the tool does and what it returns. No gaps for the intended use case.

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

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

Only one parameter 'domain' with schema description coverage 0%. The description adds 'Domain name (e.g. 'example.com')', which provides an example and clarifies the expected format, adding value beyond the bare schema.

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

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

The description clearly states the action ('Look up WHOIS information') and the resource ('a domain'). It specifies the output fields (registrar, dates, nameservers), distinguishing it from sibling tools like dns_lookup or ip_geolocation.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., dns_lookup, ssl_check). The description implies usage for WHOIS data but does not state exclusions or prerequisites.

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

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

Annotations already provide readOnlyHint and openWorldHint. Description adds value by specifying the types of data returned (tech stack, theme, apps, traffic, metadata), which goes beyond the annotation hints. No contradictions.

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

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

Two sentences, no unnecessary words. First sentence states purpose and outputs, second explains the parameter. Efficient and front-loaded.

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

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

Given one parameter, no output schema, and annotations present, the description is adequate. It provides enough context about the output without needing to detail return structure. However, it does not mention any potential limitations or error conditions.

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

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

The parameter 'url' has no description in the schema (0% coverage). The description compensates by providing an example and format ('Shopify store URL (e.g. 'https://store.example.com')'), clarifying what is expected.

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

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

Description clearly defines the tool's purpose with specific verb ('Analyze'), resource ('Shopify store'), and enumerates outputs (tech stack, theme, apps, traffic estimates, store metadata). It distinguishes from sibling tools like 'get_store_products' which focuses only on products.

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

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

No guidance on when to use this tool versus alternatives. While it mentions analyzing a store, it does not provide context for when to choose this over sibling tools like 'get_store_products' or other ecommerce tools.

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

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

Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true (results may vary). The description adds that it returns specific fields, but does not disclose pagination, error handling, or limits beyond the default max_results.

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

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

The description is extremely concise: a single sentence for purpose followed by a formatted argument list. No unnecessary words, and critical information is front-loaded.

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

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

For a simple read tool with two parameters and no output schema, the description covers the return fields and parameter meaning. Minor gaps: does not mention if pagination is supported or the URL format restrictions.

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

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

With 0% schema description coverage, the description compensates by explaining the 'url' parameter (example provided) and 'max_results' (default 20), adding meaning beyond the raw schema.

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

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

The description clearly states the tool retrieves products from a Shopify store, listing specific data fields (prices, titles, images, variants). It distinguishes from the sibling 'analyze_shopify_store' by focusing on listing rather than analysis.

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

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

No guidance on when to use this tool versus alternatives (e.g., 'analyze_shopify_store'). The description only explains what it does, lacking context for selection or exclusions.

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

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

Annotations declare readOnlyHint and openWorldHint, so the agent knows it's a safe query. The description adds parameter behavior (empty for top coins, max_results default) but does not mention rate limits, data freshness, or any caveats.

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

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

The description is concise, with a clear header and param list. No unnecessary text.

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

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

The description covers tool purpose, parameter usage, and return fields. It lacks details on output structure (e.g., JSON format) and error conditions, but given the tool's simplicity, it is largely complete.

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

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

With 0% schema description coverage, the description fully covers the parameter semantics: it explains the format and behavior of both parameters, including the example for coins and default for max_results. It adds significant value.

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

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

The description clearly states it gets cryptocurrency prices and market data from CoinGecko, listing specific metrics. However, it does not differentiate itself from the sibling tool 'crypto__crypto_prices', which likely has a similar function.

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

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

The description lacks any when-to-use or when-not-to-use guidance relative to sibling tools. It does not mention alternatives or prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's burden is lower. It adds that the tool returns conversion rates for major currencies, but does not elaborate on data source, update frequency, or rate limits. Adequate but not rich.

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

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

Extremely concise: two sentences plus a one-line parameter description. The category prefix '[Finance & Markets]' is helpful for organization. No filler or redundant information.

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

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

Given the simplicity of the tool (one optional parameter, no output schema), the description covers the essential purpose and parameter. However, it lacks details about the return format or which currencies are considered 'major', which would help agents fully understand the output.

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

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

With 0% schema description coverage, the description compensates by defining the base_currency parameter with examples ('USD', 'EUR', etc.). It adds meaning beyond the schema's bare type declaration, though the default value (USD) from schema is not repeated.

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

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

Description clearly states it gets current currency exchange rates for major world currencies, with specific verb and resource. The name and examples (USD, EUR, GBP, JPY) differentiate it from crypto-related siblings like crypto__exchange_rates and finance__get_crypto_prices.

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

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

No explicit guidance on when to use this tool versus alternatives like finance__get_stock_data or crypto__exchange_rates. The description does not mention when not to use it or provide context for selecting it over other financial tools.

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

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

Annotations provide readOnlyHint=true and openWorldHint=true, which the description reinforces by stating it returns data. The description adds behavioral detail on the data content (price, volume, etc.), but does not address potential errors, rate limits, or data freshness. It adds some value beyond annotations.

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

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

The description is concise: a single sentence outlining purpose, followed by the args section. It is front-loaded and contains no unnecessary verbiage.

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

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

Given the lack of output schema, the description lists key return data (price, volume, market cap, PE ratio, dividend yield, historical data), which is adequate. However, it does not specify date ranges for historical data, error handling, or data format, leaving some gaps for a complete understanding.

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

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

The single parameter 'ticker' has 0% schema description coverage. The description compensates by providing a clear definition ('Stock ticker symbol') and examples (AAPL, GOOGL, TSLA, MSFT), making the parameter's meaning and usage clear.

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

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

The description clearly states the verb 'Get' and resource 'stock market data' for a ticker from Yahoo Finance, listing specific data points (price, volume, market cap, PE ratio, dividend yield, historical data). It distinguishes from some siblings by being specific to single stock data, but does not explicitly differentiate from similar tools like yahoo-finance__get_stock_quote.

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

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

No guidance on when to use this tool versus alternatives (e.g., finance__screen_stocks, yahoo-finance__get_stock_quote). The description lacks explicit context for selection.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds no contradictory behavior and reinforces the read-only nature. It does not give additional behavioral context such as rate limits or return format that would raise transparency beyond annotations.

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

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

The description is efficiently structured with a clear purpose line followed by concise parameter documentation. No redundant information, and the example adds practical value.

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

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

Given no output schema, the description should at least hint at return content (e.g., stock data fields). It omits this, and also lacks information on pagination or result limits beyond the `max_results` param. Adequate but not fully complete.

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

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

Although the schema has no parameter descriptions (0% coverage), the tool description's Args section clearly explains both `screener_url` (with example) and `max_results`, adding meaning beyond type and default values. This compensates well for the schema gap.

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

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

The description states it screens stocks using Finviz screener with filters like market cap, sector, PE ratio. It distinguishes from sibling country-specific screeners by not limiting to a particular market, but fails to explicitly clarify its market scope, causing potential confusion with global-equities-screener__screen_us_finviz.

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

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

No guidance on when to use this tool versus the similar sibling `global-equities-screener__screen_us_finviz` or other finance tools. The description does not specify prerequisites, exclusions, or context-appropriate scenarios.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description carries less burden. It adds that the tool returns specific data fields (prices, changes, market caps) which is helpful but does not disclose additional behaviors such as data freshness or rate limits. No contradiction with annotations.

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

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

The description is extremely concise: one sentence for purpose and returns, followed by a clear Args block. No superfluous content; front-loaded with category and purpose.

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

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

For a simple read-only tool with one parameter and no output schema, the description adequately covers what the tool does and what it returns. The only minor gap is lack of explicit mention of currency or data source, but that is likely implied.

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

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

The input schema has 0% description coverage, but the description compensates by explaining the 'coins' parameter as a comma-separated list of coin IDs with an example. This adds significant meaning beyond the schema's type and default value.

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

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

The description clearly states the tool tracks real-time prices for a portfolio of cryptocurrencies and lists returned data (current prices, 24h changes, market caps). However, it does not explicitly distinguish from the sibling tool 'finance__get_crypto_prices', which likely serves a similar function, relying only on the name and context for differentiation.

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

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

The description implies usage for tracking multiple cryptocurrencies but does not provide explicit guidance on when to use this tool vs. alternatives like 'finance__get_crypto_prices'. No when-not-to or exclusion criteria are given.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds 'side by side' but does not explain what data is compared (e.g., stars, forks, languages). This lack of behavioral detail leaves the agent uncertain about the output.

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

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

Description is concise: one sentence for purpose followed by a clear parameter definition. No extraneous information, front-loaded with the key action.

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

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

With no output schema and low parameter coverage, the description should clarify what the comparison entails. It only says 'side by side' without specifying metrics or return structure, leaving significant gaps for a complex tool.

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

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

Input schema has 0% coverage for the 'repos' parameter. The description compensates by specifying the format ('owner/repo' strings) and providing an example, which adds meaningful guidance beyond the schema.

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

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

Description clearly states the tool compares multiple GitHub repositories side by side. The verb 'compare' and resource 'repositories' are specific, and it distinguishes from sibling tools like search_repos or get_repo_stats.

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

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

Description explains to provide repos as 'owner/repo' strings and gives an example. It does not explicitly state when not to use this tool or mention alternatives, but the unique purpose among siblings is clear enough.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds no behavioral details beyond stating it provides a 'breakdown' of languages, which is minimal. No contradiction with annotations.

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

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

The description is concise, with the purpose stated upfront. The Args section repeats what is in the schema but does not harm. Could be slightly tighter by removing redundancy.

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

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

For a simple read tool with two plain string parameters and no output schema, the description is largely complete. It explains the output conceptually, though a brief note on the return structure (e.g., map of language to bytes) would improve it.

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

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

With 0% schema description coverage, the description compensates by providing concrete examples for both parameters (e.g., 'microsoft' and 'vscode'), adding meaning beyond the schema's type and required constraints.

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

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

The description clearly states the tool gets the programming language breakdown for a GitHub repository, using a specific verb and resource. It distinguishes from sibling tools like github__get_repo_stats and github__compare_repos by focusing on languages.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. While the purpose is clear enough for a simple read tool, it does not mention when not to use it or suggest other tools for related tasks.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds that the tool returns stars, forks, issues, and activity, but does not disclose return format, pagination, or any edge-case behaviors. With annotations covering the core behavioral traits, a score of 3 is appropriate.

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

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

The description is concise with three sentences plus an Args section. It is front-loaded with the purpose and includes necessary parameter details without extraneous information. Every sentence adds value.

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

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

Given the tool has no output schema, the description could be improved by mentioning the return format or data freshness. However, it does list the kinds of data included (stars, forks, issues, activity) and provides parameter examples. It is adequate but not fully comprehensive.

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

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

Two parameters (owner, repo) have 0% schema description coverage. The description compensates fully by explaining each parameter with examples: owner is 'Repository owner/organization (e.g. 'facebook')' and repo is 'Repository name (e.g. 'react')'. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool retrieves detailed statistics for a GitHub repository including specific metrics like stars, forks, issues, and activity. It uses specific verbs and resources, and distinguishes itself from sibling tools such as github__get_repo_languages and github__compare_repos.

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

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

The description provides no guidance on when to use this tool vs. alternatives like developer-tools__get_github_repo or github__search_repos. There is no mention of use cases, prerequisites, or 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds value by specifying return fields, default sort, and max_results, but does not contradict annotations.

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

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

Description is concise, front-loaded with purpose, and uses clear line breaks for args. Every sentence adds value with no redundancy.

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

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

For a simple 3-parameter tool with no output schema, description adequately covers return fields and parameter behavior. Meets completeness needs.

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

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

Schema coverage is 0%, but description explains all three parameters: query usage, sort options with examples and default, and max_results with default. This compensates fully for missing schema descriptions.

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

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

Description clearly states 'Search GitHub repositories by query' and lists return fields (names, descriptions, stars, forks), providing a specific verb-resource pair that differentiates from sibling tools like github__get_repo_stats.

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

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

No guidance on when to use this tool vs alternatives (e.g., developer-tools__get_github_repo for single repo details). Does not mention when not to use it or prerequisites.

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

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

Annotations provide readOnlyHint (true) and openWorldHint (true). The description adds coverage scope (ASX 200 + small-caps) but does not disclose other behavioral traits like pagination or result format. With annotations covering safety, description adds modest value.

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

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

The description is two sentences: one for purpose, one for args. No wasted words, front-loaded with key information.

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

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

Given no output schema, the description does not explain return values or pagination. For a screening tool, output format is important. However, annotations cover safety and open-world hint. Somewhat incomplete.

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

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

Schema description coverage is 0%, but the description explains both parameters: 'criteria: filter dict (sector, market cap, etc.)' and 'limit: max rows to return'. This adds meaning beyond the bare schema types.

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

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

The description clearly states it screens Australian Securities Exchange (ASX) including ASX 200 and small-caps, with specific mention of mining juniors. This distinguishes it from sibling tools for other exchanges (e.g., screen_brazil_b3).

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

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

The description implies usage for ASX stocks, and the tool name indicates the exchange. While no explicit alternatives or when-not-to-use are given, the context of sibling tools for other exchanges makes usage clear.

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

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

Annotations already provide readOnlyHint and openWorldHint. Description adds that criteria includes examples like sector and market cap, but no details on return behavior, pagination, or rate limits. Minimal added value beyond annotations.

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

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

Very concise: only three sentences with a clear purpose line and a bullet-style Args section. No redundant information; every sentence adds value.

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

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

For a two-parameter tool with annotations covering read-only and open-world hints, the description is largely complete. Missing return format details, but not critical given the schema and hints. Adequate for an AI agent.

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

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

Schema has 0% description coverage; description adds meaning by explaining 'criteria' as a filter dict with examples and 'limit' as max rows. This compensates for the missing schema descriptions, though the exact format of criteria remains vague.

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

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

Description explicitly states the action ('Screen') and the resource ('Brazil's B3 exchange') with specific indices mentioned (Bovespa, Small Caps). The name itself already distinguishes from many sibling country-specific screeners.

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

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

Implied usage from sibling tools (other country screeners), but no explicit when-to-use or when-not-to-use guidance or alternatives stated. The description assumes the user knows to use this for Brazilian equities.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds context about exchange composition (mining/energy heavy) but no additional behavioral traits beyond what annotations provide.

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

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

Description is two sentences plus arg explanations, concise and front-loaded with no extraneous information.

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

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

Given the tool has 2 parameters (one optional object) and no output schema, the description sufficiently covers purpose, exchange scope, and parameter meanings. Could be improved by mentioning output format or edge cases.

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

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

Schema description coverage is 0%, but description explains 'criteria: filter dict (sector, market cap, etc.)' and 'limit: max rows to return', adding meaning beyond the raw schema properties.

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

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

Description clearly states it screens Toronto Stock Exchange (TSX) including TSX Composite and TSX Venture, with a note about mining/energy focus. It distinguishes from siblings which target other exchanges.

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

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

The description implicitly indicates use for Canadian equities but does not explicitly state when to use this tool over alternative country-specific screeners like screen_us_finviz or screen_australia_asx.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external dependency profile is covered. The description adds the data source (Eastmoney) and parameter defaults, but does not disclose any other behavioral traits like pagination, rate limits, or exact output format. This adds some value but is not rich in behavioral detail.

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

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

The description is extremely concise: one line for purpose and a bulleted parameter list. It is front-loaded with the key action and resource, and every sentence or bullet adds essential information without filler.

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

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

The description adequately covers purpose and parameters, but lacks any indication of what the output looks like (columns, format) or whether there is pagination beyond the default limit. For a screener tool, this missing output detail makes it somewhat incomplete, but given the simplicity of the tool and the annotations, it is minimally adequate.

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

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

Despite 0% schema description coverage, the 'Args' section in the description provides meaningful semantic explanations for each parameter: sector includes examples, market_cap_min specifies currency (CNY), and limit notes the default value. This fully compensates for the missing schema descriptions.

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

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

The description clearly states it screens Mainland China A-shares (Shanghai + Shenzhen) via Eastmoney data, using a specific verb and resource. It distinguishes itself from sibling tools that target other markets, making the purpose unmistakable.

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

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

The description implicitly indicates when to use this tool (for China A-shares) by naming the market, but it does not explicitly state when not to use it or mention alternatives. The context of sibling tools covering different markets provides clear differentiation, but direct guidance is absent.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds that it is a filtering/screening tool with criteria and limit, which is consistent. No contradictions, but no deep behavioral insights beyond annotations.

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

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

The description is extremely concise: a clear purpose line followed by two short parameter descriptions. No wasted words, front-loaded with purpose.

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

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

For a simple two-parameter screening tool with no output schema, the description covers the core functionality and parameters. It is slightly lacking in describing return format, but overall sufficient.

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

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

With 0% schema description coverage, the description adds critical meaning: criteria is a 'filter dict (sector, market cap, etc.)' and limit is 'max rows to return'. This compensates well, though more detail on criteria keys would be better.

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

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

The description clearly states the tool screens the Beijing Stock Exchange (BSE) for SME stocks, using a specific verb ('screen') and resource. It distinguishes from sibling tools like screen_china_a_shares by naming BSE and SME.

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

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

The description implies use for BSE SME screening but provides no explicit when-to-use or when-not-to-use guidance. No alternative tools are mentioned despite many Chinese market screeners as siblings.

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

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

Annotations already declare readOnlyHint: true, so the description's mention of 'screen' is consistent. No additional behavioral traits (e.g., data freshness, rate limits) are disclosed. The description adds minimal context beyond annotations.

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

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

The description is two sentences plus an args list. Purpose is front-loaded in the first line. Every sentence adds value without redundancy.

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

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

With no output schema, the description could mention return format or pagination. It is adequate for a simple screening tool but lacks depth on filtering capabilities and response structure.

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

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

Schema coverage is 0%, but the description explains 'criteria' as a filter dict (sector, market cap, P/E, etc.) and 'limit' as max rows. This adds meaning, though details on allowed criteria keys are absent. The schema's open-ended object is unconstrained, so extra guidance would help.

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

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

The description clearly states it screens ChiNext (Shenzhen growth board) for growth companies, referring to it as China's Nasdaq-equivalent. This is a specific verb+resource that distinguishes it from other screen tools for different exchanges.

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

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

No guidance on when to use this tool versus alternatives like screen_china_a_shares or screen_china_bse. The description does not mention exclusions or conditions for selecting ChiNext. Usage is implied by the market name only.

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

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

Annotations provide readOnlyHint (safe read) and openWorldHint (external data). Description adds market specificity and args, but does not elaborate on response format, pagination, or potential side effects. With annotations present, additional behavioral context is minimal but consistent.

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

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

Two concise sentences plus an Args list. Purpose front-loaded, no wasted words. Efficient structure for quick consumption.

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

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

Covers purpose and parameters adequately, but missing return format information. With no output schema, description should at least indicate what data fields or shape to expect. Also lacks comparison to siblings for selection guidance.

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

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

At 0% schema description coverage, description compensates with clear explanations: 'dict of filters' for criteria (with example) and 'max rows to return' for limit. However, possible filter keys are not enumerated.

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

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

Description clearly states the verb ('Screen'), specific resource ('China's STAR Market'), and scope ('Chinese hard-tech & biotech IPOs'), distinguishing it from other market-specific screeners.

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

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

Implicit market targeting via name and description, but no explicit guidance on when to choose this over other Chinese market screeners (e.g., A-shares, ChiNext) or other global tools.

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

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

Annotations already mark the tool as readOnlyHint=true and openWorldHint=true. The description adds no behavioral traits beyond the purpose (screening). It does not disclose data fields, pagination behavior, or any constraints.

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

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

The description is three lines: a title line and an Args section with two parameters. It is front-loaded, concise, and contains no unnecessary information.

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

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

For a simple tool with no output schema and well-understood parameters, the description is largely complete. It covers purpose and parameter guidance. However, it does not describe the return format or any limits, which could be helpful.

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

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

The schema has zero description coverage, so the description must compensate. It explains 'criteria: filter dict (sector, market cap, P/E, etc.)' and 'limit: max rows to return'. This adds useful meaning beyond the raw schema, though it could be more detailed.

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

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

The description clearly states it screens Chinese ADRs listed on US exchanges, with examples (Alibaba, JD, PDD, NIO). This distinguishes it from sibling screeners for other markets (e.g., screen_us_finviz, screen_australia_asx).

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

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

The description implies usage for Chinese ADRs, but does not provide explicit when-to-use, when-not-to-use, or alternatives. Given the many sibling screeners, additional guidance would be beneficial.

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

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

Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true. The description adds value by specifying the indices and parameter behavior. However, it does not disclose potential rate limits or default behavior when criteria is null.

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

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

The description is extremely concise: two sentences plus an argument list. Every sentence serves a purpose, with the main action quoted at the beginning. No unnecessary words.

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

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

The description covers purpose and parameters well, but lacks details about output format or what happens when criteria is null. Given the tool's simplicity and the presence of similar tools, it is nearly complete.

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

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

With 0% schema description coverage, the description compensates fully by explaining 'criteria: filter dict (sector, market cap, P/E, etc.)' and 'limit: max rows to return'. This adds essential meaning beyond the schema's type and default.

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

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

The description clearly states the tool screens Xetra/Deutsche Börse equities covering DAX 40, MDAX, SDAX, and TecDAX. It uses the verb 'screen' and specifies the exact resource, distinguishing it from siblings targeting other markets.

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

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

The description implicitly indicates it's for German equities via the tool name and index list, but does not explicitly state when to use it versus alternatives or provide exclusion criteria. Context is clear but guidance is not explicit.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that the limit parameter specifies maximum rows returned, providing some behavioral context. However, it does not disclose data freshness, rate limits, or output format details.

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

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

The description is extremely concise yet informative, consisting of a one-line purpose statement followed by clear parameter explanations. No unnecessary words or repetition.

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

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

For a simple two-parameter tool with annotations, the description covers the key aspects: market coverage, parameter semantics, and basic behavior. It could be improved by mentioning the output type (e.g., list of stocks) but is largely complete.

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

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

With 0% schema description coverage, the description adds significant meaning: it explains criteria as a filter dict with example keys (industry, market cap, P/E, dividend yield) and clarifies limit as max rows. This compensates well for the lack of schema descriptions.

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

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

The description explicitly states it screens Hong Kong-listed stocks via HKEX, covering Hang Seng, Mainboard, and GEM. The verb 'Screen' and resource 'Hong Kong-listed stocks' are specific and distinguish it from siblings targeting other markets.

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

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

The description clearly indicates this tool is for Hong Kong stocks, providing usage context. However, it lacks explicit exclusions or alternatives, such as when not to use it or mention of other screening tools for different regions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds parameter context but no additional behavioral details (e.g., rate limits, pagination, output format). It does not contradict annotations, but adds minimal value beyond them.

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

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

The description is extremely concise: two sentences plus parameter notes. Every sentence serves a purpose, and the main action is front-loaded. No redundancy or trivia.

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

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

Given no output schema, the description does not explain the return format (e.g., list of dictionaries, fields). The criteria parameter is only vaguely described. While adequate for a simple tool, it misses details that would fully inform an agent.

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

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

With 0% schema description coverage, the description adds meaning by explaining criteria as a filter dict (sector, market cap, P/E, etc.) and limit as max rows. This compensates for missing schema descriptions, though exact keys or value types are unspecified.

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

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

The description clearly states the tool screens India's National Stock Exchange (NSE), specifying Nifty 50, Nifty Bank, and full universe. This clearly distinguishes it from sibling screeners for other exchanges.

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

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

The description implies usage for NSE screening but does not explicitly guide when to use this tool versus alternatives like finance__get_stock_data or other screeners. No when-not or alternative suggestions are provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no behavioral traits beyond these, such as rate limits, pagination, or response details. It does not contradict annotations, so it meets a baseline but adds little extra value.

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

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

The description is two sentences plus a concise arg list. It front-loads the main purpose and efficiently conveys parameter roles with minimal redundancy.

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

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

Given the tool's simplicity (2 params, no output schema) and annotations covering read-only/open-world aspects, the description reasonably explains purpose and parameters. It lacks details on exact indices or criteria constraints, but is sufficient for a screener tool.

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

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

With 0% schema description coverage, the description provides meaning for both parameters: criteria is described as a filter dict with examples (sector, market cap) and limit as max rows. This adds useful context beyond the schema, though more detail on criteria keys would improve it.

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

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

The description clearly states it screens Indonesia Stock Exchange (IDX) for specific indices (LQ45, IDX30, full Jakarta board), with a specific verb 'Screen' and resource 'Indonesia Stock Exchange'. This effectively distinguishes it from sibling tools for other exchanges and related screeners.

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

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

The description provides clear context that this tool is for Indonesia-specific screening. It implies usage for Indonesian equities but does not explicitly mention when not to use it or provide alternative tools. The sibling list includes other country screeners, so the naming and description sufficiently guide selection.

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

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

Annotations provide readOnlyHint and openWorldHint, so safety is already conveyed. Description adds the specific market context but no additional behavioral details such as pagination 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.

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

Concise, well-structured with a header and bullet-like args. No wasted words.

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

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

Covers basic purpose and parameters but lacks details on output format, criteria structure, and pagination. Adequate for a simple tool but not fully complete given no output schema.

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

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

Schema has 0% description coverage. Description lists examples for criteria (sector, market cap, etc.) and explains limit, but is vague with 'etc.' and does not fully document the parameter semantics.

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

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

Description clearly specifies the verb 'Screen' and the specific stock exchange (TSE) with indices and market segments, distinguishing it from sibling screeners for other markets.

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

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

Implicitly clear that this tool is for Japanese equities, but no explicit guidance on when to use vs alternatives like finance__screen_stocks or other country screeners.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds no behavioral details beyond those annotations (e.g., no mention of mutability, rate limits, or output format). It does not contradict annotations.

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

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

The description is extremely concise—two lines plus argument summaries. It front-loads the purpose and includes only essential information. No unnecessary words.

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

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

Given the simple tool (2 params, no output schema), the description covers the purpose and parameter semantics. However, it lacks description of the output/return format, which may be needed by the agent. Annotations provide some context but not completeness.

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

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

Schema description coverage is 0%, but the description adds meaning: 'criteria: filter dict (industry, market cap, P/E, etc.)' clarifies the purpose of the criteria parameter, and 'limit: max rows to return' explains the limit parameter. This compensates for missing schema descriptions.

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

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

The description clearly states it screens Korea's KOSPI exchange with examples like Samsung, SK Hynix. It uses a specific verb (Screen) and resource (KOSPI exchange). Though not explicitly differentiated from sibling screen tools, the name and prefix sufficiently distinguish it.

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

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

No guidance on when to use this tool versus alternatives. No prerequisites, conditions, or exclusions are mentioned. The description is generic and does not help the agent decide between this and other screen tools.

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

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

The annotations already declare readOnlyHint=true, so the description's addition of the specific market scope (FBM KLCI and Main Market) provides useful context but does not disclose further behavioral traits like pagination, rate limits, or data freshness. It does not contradict annotations.

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

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

The description is concise—two sentences plus a clean args listing. It is front-loaded with the purpose and wastes no words. Every sentence contributes to understanding.

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

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

Despite the simplicity, the tool lacks an output schema and the description does not explain the return format or fields. The criteria parameter is loosely typed, and only two example keys are given. For a screening tool, the agent needs to know what data comes back and all possible filter options to use it effectively.

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

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

With 0% schema description coverage, the description adds meaningful context: it explains that 'criteria' is a filter dict with examples (sector, market cap) and that 'limit' controls max rows. This goes beyond the bare schema, though a full list of supported filter keys would be more complete.

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

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

The description clearly states the tool screens Bursa Malaysia, specifically FBM KLCI components and Main Market. The verb 'screen' is appropriate, and the market name distinguishes it from many sibling screeners for other countries.

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

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

The description implies usage for Malaysian equities but does not provide explicit guidance on when to use this tool versus other country-specific screeners or similar finance tools. There is no mention of when-not-to-use or alternatives, leaving the agent to infer from the market name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety profile is covered. The description adds that it covers IPC components and broader universe, but does not disclose additional behavioral traits like pagination 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.

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

The description is two concise sentences plus an arg list with no fluff. The group label in brackets provides context. Every part earns its place.

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

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

With no output schema, the description does not explain return format. It covers basic purpose and parameters but lacks details on output structure or limitations beyond defaults.

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

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

With 0% schema description coverage, the description provides basic meaning: 'criteria' is a filter dict (sector, market cap, etc.) and 'limit' is max rows. This is helpful but not detailed beyond the schema's structure.

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

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

The description clearly states the tool screens the Bolsa Mexicana de Valores (BMV) for IPC components and broader Mexican universe. The verb 'screen' plus specific resource distinguishes it from sibling tools that screen other exchanges.

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

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

The context is clear: use this tool for Mexican equities. While there is no explicit exclusion or alternative mentioned, the naming and description imply it is for BMV stocks, matching sibling pattern.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds no extra behavioral context beyond the screening purpose. No destructive or side effects mentioned, which aligns with annotations.

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

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

Two concise sentences with no wasted words. Information is front-loaded: tool category, market, then parameters. Ideal length for this complexity.

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

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

Covers both parameters and the market scope. No output schema exists, and description does not detail return format, but for a simple screening tool this is adequate. Could mention price or metadata fields returned.

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

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

Schema coverage is 0% (no parameter descriptions in schema). Description explains 'criteria' as a filter dict with examples like sector and market cap, and 'limit' as max rows. This adds meaningful value beyond the raw schema.

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

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

Description clearly states the tool screens Philippine Stock Exchange (PSE) stocks including PSEi components and broader market. The verb 'screen' is specific and distinguishes from sibling tools targeting other exchanges.

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

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

No explicit guidance on when to use or when not. The description implies usage for Philippines equity screening but does not mention alternatives or exclude other tools. Usage is inferred rather than directed.

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

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

Annotations indicate readOnlyHint and openWorldHint; description adds that it screens filters by criteria (sector, market cap, dividend yield) and limits rows. No contradictions. Provides useful behavioral context beyond the annotations.

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

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

Concise, front-loaded with purpose, and includes parameter descriptions in a clean format. One extraneous 'etc.', but overall efficient.

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

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

Missing output format/return value description. With no output schema, the agent needs to know what fields the results contain. Incomplete for a screening tool.

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

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

Schema coverage is 0%; description partially compensates by explaining criteria is a filter dict with examples (sector, market cap, dividend yield) and limit is max rows. However, no exact structure or allowed keys for criteria, leaving ambiguity.

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

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

Clearly states it screens Saudi Arabia's Tadawul exchange, providing specific examples (TASI, Aramco, banks, petrochems). Differentiates well from sibling tools that cover other markets.

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

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

Clear context for use: screening Saudi stocks. No explicit when-not or alternatives, but sibling list implies this is for Saudi-specific screening. Could specify that for other markets, use the corresponding screen tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context on the universe screened (STI & REITs) but does not disclose pagination, error handling, or behavior beyond filtering. With annotations, this is acceptable but not rich.

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

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

The description is extremely concise: one line for purpose, one line for arguments. No wasted words, front-loaded with the primary function.

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

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

Given no output schema and only two optional parameters, the description covers the exchange, universe, and parameter semantics. It could optionally mention return format but is sufficiently complete for a screening tool.

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

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

Schema coverage is 0%, so description must compensate. It explains 'criteria' as a filter dict with examples (sector, market cap, dividend yield) and 'limit' as max rows. This adds meaningful context beyond the schema, though more specific keys would be helpful.

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

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

The description clearly states the tool screens the Singapore Exchange (SGX) specifically for STI components and SE-Asia REIT universe. It uses specific verb+resource+scope, and the sibling tools for other exchanges make the differentiation clear.

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

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

The description implicitly indicates this tool is for SGX screening, with sibling tools for other exchanges. However, it lacks explicit guidance on when-to-use vs alternatives or when-not-to-use, but the context is clear enough for an agent.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, indicating a read-only, open-ended query tool. The description adds that it screens JSE stocks, which is consistent but does not disclose additional behavioral traits (e.g., rate limits, auth requirements, or result size limits beyond the limit parameter).

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

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

Extremely concise: one sentence for purpose, then a bulleted Args section. No wasted words, front-loaded with the exchange name. Perfectly structured for quick reading.

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

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

Adequate for a simple tool with two parameters, but missing description of return format (no output schema). The optional segments list (Top 40, etc.) hints at possible filters but isn't explained. For completeness, a note on what the output contains (e.g., stock symbols, prices) would be helpful.

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

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

Schema has 0% description coverage; the description compensates by explaining 'criteria' as a filter dict with examples (sector, market cap, etc.) and 'limit' as max rows. This adds meaning beyond the schema, though the criteria parameter remains loosely defined due to its open-ended nature.

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

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

Description clearly states the tool screens the Johannesburg Stock Exchange (JSE) and mentions key segments (Top 40, mining majors, financials). The verb 'screen' is appropriate. However, it doesn't specify the output format or what 'screen' entails beyond filtering, which slightly reduces clarity.

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

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

No explicit guidance on when to use this tool versus other exchange-specific screeners. The name and context of siblings (e.g., screen_australia_asx) imply usage per exchange, but the description lacks direct instructions or exclusions.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds little beyond stating it's a screening operation, consistent with readOnly. No additional behavioral context like rate limits or data freshness is provided.

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

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

Two concise sentences plus an arg list. Purpose is front-loaded. Every word serves a purpose with no redundancy.

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

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

While adequate for a straightforward screening tool, the description lacks details on available filter fields, output format, or potential query limitations. openWorldHint suggests flexibility but could be more informative given no output schema.

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

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

With 0% schema description coverage, the description compensates by explaining the criteria parameter as a filter dict with industry, market cap, P/E, etc., and limit as max rows. This adds meaning beyond the bare schema.

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

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

The description clearly identifies the tool's purpose: screening the Taiwan Stock Exchange (TWSE), with a focus on semiconductors heavyweights. It distinguishes from siblings by specifying the exchange and region.

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

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

The description implies usage for Taiwan equities but does not provide explicit guidance on when to use this vs. alternative screen tools for other exchanges, nor does it mention 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which align with a screening operation. The description adds no further behavioral disclosures about rate limits, authentication, or data freshness.

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

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

Two sentences: first states purpose, second describes arguments. No extraneous words, front-loaded, efficient.

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

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

The description covers inputs well but omits output format. Given no output schema, mentioning what the tool returns would improve completeness. Still sufficient for a screening tool with clear purpose.

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

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

With 0% schema description coverage, the description adds valuable meaning: criteria is described as a filter dict with examples (sector, market cap, dividend yield) and limit as max rows to return. This compensates well for missing schema descriptions.

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

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

The description clearly states the tool screens stocks on the Thailand Stock Exchange (SET) covering SET50, SET100, and full Thai universe. It uses a specific verb-resource combination and distinguishes well from country-specific siblings.

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

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

The description does not explicitly state when to use this tool versus alternatives. While siblings imply each tool is for a specific country, no direct usage guidance or exclusion criteria are provided.

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

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

Annotations provide readOnlyHint and openWorldHint, indicating read-only behavior and varying results. The description adds little beyond stating it screens based on criteria, which is behavioral but not detailed. No contradiction with annotations.

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

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

The description is brief and front-loaded with the market name, followed by a concise Args section. It efficiently conveys purpose but could be slightly more structured without being verbose.

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

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

Given the tool's complexity (a screener with a filter criteria object), the description is minimal. It does not explain the criteria dictionary format, possible values, or output format. No output schema exists to compensate.

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

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

Schema description coverage is 0%, but the description adds meaning by explaining criteria as a filter dict with examples (sector, market cap, dividend yield) and limit as max rows. This compensates for the lack of schema descriptions.

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

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

The description clearly states it screens the Turkish BIST market, naming specific indices (BIST 100, BIST 30) and the full universe, with a verb (screen) and resource (Borsa Istanbul). It effectively distinguishes from siblings by specifying the market.

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

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

The description implies use for Turkish equities by naming the market, but provides no explicit guidance on when to use, when not to use, or alternatives. Sibling tools cover other markets, but the description does not direct comparison or context.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description adds context about the criteria filter but does not disclose additional behavioral traits like rate limits or response format. Minimal extra value beyond annotations.

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

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

The description is extremely concise: two lines plus an args section. Key information is front-loaded, and every sentence adds value. No redundancy.

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

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

For a simple read-only screener with no output schema, the description covers purpose, market, and parameters adequately. It could mention the output format or pagination, but the provided info is sufficient.

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

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

With 0% schema description coverage, the description adds meaning by explaining 'criteria' as a filter dict with examples (sector, market cap, dividend yield) and 'limit' as max rows. This compensates for the schema's lack of descriptions.

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

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

The description clearly states 'Screen London Stock Exchange (LSE) — FTSE 100, FTSE 250, AIM' which specifies the verb (screen), resource (LSE stocks), and scope (specific indices). This distinguishes it from sibling tools for other exchanges.

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

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

The description implies when to use (for LSE screening) but does not explicitly state when not to use or provide alternatives. Given many sibling screeners, explicit usage guidance would be beneficial.

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

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

The annotations already indicate readOnlyHint: true and openWorldHint: true. The description adds value by explaining that the tool screens via Finviz, accepts flexible criteria (dict, screenerUrl, or field-specific keys), and has a limit parameter. This provides behavioral context beyond what the annotations offer, though it does not contradict them.

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

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

The description is concise, using a few sentences to convey purpose, input formats, and defaults. It is front-loaded with the main purpose, and every sentence adds value without redundancy or unnecessary detail.

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

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

Given the tool's complexity (100+ filters, multiple input formats), the description covers the essential aspects: target exchanges, acceptable criteria formats, and the limit parameter. It does not explain the output format or additional details about filter codes, but the examples provide enough context for basic use. An output schema is not present, so no further detail is required.

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

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

Schema description coverage is 0%, but the description compensates by explaining the criteria parameter in detail: it accepts Finviz filter codes, a screenerUrl for pre-built screens, or field-specific keys like market_cap_min. It also clarifies the limit parameter's default (50). This adds substantial meaning beyond the schema's minimal definition.

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

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

The description clearly states 'Screen US-listed stocks (NYSE/NASDAQ/AMEX) via Finviz with 100+ filters.' It specifies the verb (screen), the resource (US-listed stocks), and the method (Finviz filters), distinguishing it from sibling tools like screen_australia_asx by explicitly naming the US exchanges.

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

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

The description does not explicitly provide guidance on when to use this tool versus alternatives. It implies the context by specifying US stocks, but there is no direct comparison or exclusionary language. The sibling tools for other countries are listed, but the description alone does not guide the agent on selecting this one.

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

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

Annotations already provide readOnlyHint and openWorldHint, and description adds scope information (VN30 + full HOSE) but no additional behavioral traits beyond what annotations convey.

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

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

Description is concise (4 lines) with front-loaded purpose and clear bullet list for parameters; no extraneous text.

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

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

For a simple tool with two optional params and annotations present, the description covers purpose, scope, and param semantics adequately; no output schema but not required given simplicity.

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

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

Schema coverage is 0%, but description explains 'criteria' as a filter dict with examples (sector, market cap) and 'limit' as max rows, adding significant semantic value beyond the schema's default values.

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

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

Description clearly states the tool screens Vietnam's HOSE exchange covering VN30 and full board, distinguishing it from sibling tools for other exchanges.

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

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

Context is clear from name and description that this tool is for Vietnam HOSE; sibling tools imply alternatives, but no explicit when-to-use or 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.

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

Annotations declare readOnlyHint=true, and the description's 'scraping' is consistent. However, it does not disclose potential rate limits, data accuracy, or scraping policy implications, which would 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.

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

The description is concise and front-loaded with purpose, but the Args section could be more compact. Still, every sentence adds value.

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

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

The description covers all key parameters and high-level return data. Lacks details on output format, pagination, or practical usage limits, but sufficient for a straightforward lead generation tool.

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

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

Despite zero schema description coverage, the description provides clear, detailed parameter descriptions with examples (e.g., business_type, city, state) and defaults for max_results, adding significant meaning beyond the schema.

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

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

The description clearly states the tool generates B2B leads by scraping Google Maps businesses with contact info, listing specific return fields. It distinguishes from sibling tools like 'search_local_businesses' by focusing on lead generation with contact details.

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

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

No explicit guidance on when to use this tool versus alternatives like 'google-maps__search_local_businesses' or 'google-maps__validate_emails'. The description lacks context for tool selection.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it returns specific business details and specifies default max_results=20, which is useful. However, it does not cover pagination, rate limits, or data freshness, so it adds some but not extensive behavioral context.

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

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

The description is concise: one sentence for purpose followed by a bulleted list of arguments. No filler, information is front-loaded and well-organized.

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

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

For a simple search tool with 3 parameters and no output schema, the description covers purpose, return fields, and parameters adequately. However, it lacks context about when to use versus siblings like generate_leads, and does not mention ordering or filtering options.

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

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

Schema description coverage is 0%, but the description provides clear explanations for all 3 parameters: query with examples, location with examples, and max_results with default. This adds significant meaning beyond the bare schema types.

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

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

The description clearly states the tool searches Google Maps for local businesses and lists the returned data fields (names, addresses, ratings, phone numbers, websites). It differentiates from siblings like google-maps__generate_leads and google-maps__validate_emails by focusing on search.

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

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

No explicit guidance on when to use this tool vs alternatives like generate_leads or validate_emails. The description implies usage for general local business search but does not provide context for exclusion or preferred scenarios.

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

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

Annotations indicate read-only and open world hints. The description adds that it checks syntax, domain, and deliverability, providing more behavioral detail beyond annotations.

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

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

Very concise, with the purpose stated first. Every sentence is useful, and the docstring format is efficient.

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

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

The description covers the tool's purpose and parameter but does not mention the output format or any potential limitations, such as rate limits or number of emails supported.

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

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

With 0% schema coverage, the description compensates by defining the 'emails' parameter as a list of email addresses and providing an example. This adds meaning beyond the schema's type definition.

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

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

The description clearly states the tool validates email addresses, checking syntax, domain, and deliverability. It is distinct from siblings like sales-intelligence__find_company_emails.

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

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

No explicit guidance on when to use this tool versus alternatives. While not competitive with siblings, the description lacks context on prerequisites or limitations.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds context by listing the returned fields (employer, job title, salary, location, case status) and the three parameters, which helps the agent understand behavior.

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

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

The description is very concise: a one-sentence purpose, a list of return fields, and an args section with examples. No redundant information, front-loaded, and well-structured.

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

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

The description adequately covers return fields and parameters. However, it lacks details on pagination, result limits, or default number of results. Given the output schema is absent, this is a minor gap.

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

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

With 0% schema description coverage, the description adds significant meaning by listing parameters with example values (e.g., 'software engineer', 'San Francisco'), compensating for the lack of schema descriptions.

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

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

The description clearly states it searches H1B visa salary data and returns specific fields. However, it does not differentiate from sibling tools like 'hr-compensation__search_salaries' or 'job-market__salary_search'.

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

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

The description implies usage for H1B salary searches with example parameter values, but it does not explicitly state when to use this tool over alternatives or provide any when-not guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, indicating a safe, read-only operation with open data. The description adds no behavioral details beyond what annotations convey, such as data source or pagination behavior. It does not contradict annotations.

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

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

The description is concise at four lines, front-loaded with the category '[HR & Compensation]' and a clear action. The parameter explanations are structured with labels and examples, with no redundant information.

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

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

Given the tool's simplicity (two parameters, no output schema, no nested objects), the description adequately covers the input parameters. However, it does not describe the output format or any limitations like data recency, but these are partially mitigated by the openWorldHint annotation suggesting the data is available.

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

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

With 0% schema description coverage, the description adds valuable meaning by providing examples for both parameters ('product manager', 'nurse' for job_title; 'New York', 'Texas' for location) and clarifies that location has a default empty string, implying it is optional. This compensates for the schema's lack of semantic hints.

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

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

The description clearly states the tool searches for 'general salary data' by job title and location, using specific verb 'search' and resource 'salary data'. It differentiates from sibling 'hr-compensation__search_h1b_salaries' which targets H1B-specific salaries, and 'job-market__salary_search' which may have broader scope.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, limitations, or when not to use it, leaving the agent to infer from the tool name alone.

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

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

Annotations declare readOnlyHint=true; description adds that it returns ratings, pros, cons, salary data. However, does not disclose potential rate limits, authentication requirements, or any other behavioral nuances.

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

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

Two concise sentences; front-loaded purpose followed by parameter list. No fluff, but could be slightly more structured (e.g., bullet points).

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

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

For a simple reviews tool with no output schema, the description names the returned data categories. Lacks details on pagination, error handling, or formatting, but adequate given low complexity.

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

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

Schema has zero description coverage, but the description provides parameter details: 'company: Company name (e.g. 'Google')' and 'max_results: Max reviews (default 20)'. Adds example and default value, compensating for schema gaps.

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

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

Clearly states it gets Glassdoor reviews for a company, listing specific data returned (ratings, pros, cons, salary data). Distinguishes from sibling tools like job-market__salary_search and job-market__search_jobs.

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

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

No guidance on when to use this tool versus alternatives; no exclusions or prerequisites mentioned. The sibling list is provided but the description gives no context for choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and data variability. The description adds that it returns employer, salary, location, which is useful but does not disclose behavioral details like rate limits or pagination. It adds moderate value beyond annotations.

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

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

The description is concise: one sentence plus an args list, front-loaded with the purpose. It is efficient but could be slightly more structured (e.g., bullet points) without losing brevity.

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

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

The tool has 2 parameters, no output schema, and is simple. The description covers parameters and return fields (employer, salary, location), which is sufficient for its complexity. No missing critical information like pagination, but not strictly necessary.

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

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

Schema has 0% description coverage, so the description compensates by explaining both parameters with examples ('Data Scientist' for job_title, 'City or state' for location). This adds significant meaning beyond the schema, though it could specify location format more precisely.

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

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

The description clearly states it searches H1B visa salary data for a job title, specifying the data source (H1B visa) and output fields (employer, salary, location). This distinguishes it from sibling tools like job-market__search_jobs (job search) and hr-compensation__search_salaries (general salary data).

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

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

The description tells when to use it (search H1B salary data) but does not explicitly provide alternatives or when not to use it. There are similar sibling tools like hr-compensation__search_h1b_salaries that may overlap, but no guidance is given to differentiate usage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that it searches Indeed and returns specific fields, but lacks details on rate limits, pagination, or other behavioral traits, making it adequate but not exceptional.

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

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

The description is concise at 5 lines, front-loaded with the purpose and then listing arguments. Every sentence serves a clear purpose.

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

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

Given the tool has 3 simple parameters and no output schema, the description provides enough information to use the tool effectively, covering input fields and return contents. It could mention error handling or format, but overall is complete.

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

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

Schema description coverage is 0%, so the description must compensate. It lists all three parameters with brief explanations and examples (e.g., query: 'software engineer'), adding significant meaning beyond the raw schema.

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

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

The description explicitly states it searches Indeed for job listings and returns titles, companies, salaries, descriptions. This distinguishes it from sibling tools like job-market__company_reviews and job-market__salary_search.

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

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

The description does not explicitly state when to use this tool instead of alternatives. While the purpose is clear, there is no guidance on when not to use it or which sibling tool to choose for different needs.

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