global-equities-screener-mcp

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

Annotations already declare readOnlyHint and openWorldHint; the description adds useful context about the stock universe (ASX 200, small-caps, mining juniors) and the filtering nature, which is 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: first states purpose, second lists args. No waste, 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?

No output schema, but the description omits return format, pagination, or detailed criteria parameters. Satisfactory for a simple screen tool 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%, so description must compensate. It provides minimal info (limit is max rows, criteria is a filter dict with vague examples) but lacks specific keys or formats for criteria.

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 name and description clearly specify screening the Australian Securities Exchange, including ASX 200 and small-caps with mining juniors, 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?

Siblings are all exchange-specific, so usage for Australian stocks is implied, but no explicit guidance on when to use vs alternatives or any prerequisites is 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 the scope (full Brazilian universe, specific indices) but no extra behavioral details like rate limits or response 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 two lines, front-loaded with purpose, followed by concise parameter descriptions. Every sentence is informative and there is 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 screening tool with only two parameters and no output schema, the description covers the exchange, indices, and parameter intent. It could mention response format but is otherwise 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?

With 0% schema coverage, the description compensates by explaining 'criteria' as a filter dict with examples (sector, market cap, dividend yield) and 'limit' as max rows. This adds useful 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 specifies 'Screen Brazil's B3 exchange (São Paulo)' and mentions specific indices like Bovespa Index and Small Caps, distinguishing it clearly from sibling tools that cover 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 Brazilian B3 stocks and describes parameters, but lacks explicit when-to-use or when-not-to-use guidance relative to siblings. The context of 'full Brazilian universe' is helpful.

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 adds value by noting the exchange composition (mining/energy heavy). However, it does not discuss rate limits, pagination, or other behavioral aspects 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?

The description is short and front-loaded with the main purpose, followed by structured Args. It avoids fluff and is efficient for its 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 2 parameters and no output schema, the description covers the basics but omits details on the criteria structure that would be necessary for correct use. Given the pattern among siblings, it is minimally adequate but not fully detailed.

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 describes criteria as a filter dict with examples (sector, market cap) and limit as max rows, but the criteria parameter is vague and lacks specific valid keys or types, 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 it screens the Toronto Stock Exchange, specifying both TSX Composite and TSX Venture, with a note on mining/energy heaviness. This clearly identifies the tool's purpose and 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 tells when to use the tool (for screening TSX stocks) and provides context about the exchange's focus. Sibling tool names further clarify usage scope, though no explicit when-not or alternative guidance is 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=true and openWorldHint=true. Description adds that it uses Eastmoney data but does not disclose any additional behavioral traits such as rate limits or return format. 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?

Extremely concise: two sentences plus parameter list. Purpose is front-loaded, and every line 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?

The description covers the purpose and parameters but is incomplete regarding output. Without an output schema, the agent has no information on what the screen returns (e.g., tickers, financials). This is a notable gap for a data retrieval 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 description coverage is 0%, so the description must compensate. It explains all three parameters: sector (with examples), market_cap_min, and limit (with default). This adds meaningful context beyond the schema, though more specifics (e.g., format for cap) could be 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?

Description clearly states it screens Mainland China A-shares via Eastmoney, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools for other Chinese exchanges (e.g., screen_china_bse, screen_china_chinext), relying on the market name alone.

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. With multiple China-focused siblings (BSE, ChiNext, Star Market), the description should indicate that this is for Shanghai/Shenzhen main boards, but it does not.

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 'Screen' which is read-only, but no further behavioral details (e.g., data freshness, scope of results, or any rate limits) 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?

Extremely concise: two lines for purpose, then structured Args. No unnecessary words. Front-loaded with the main 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?

The description covers the tool's function and parameters minimally, but omits output schema description (none exists) and criteria details. Given the complexity of screening tools, more specificity on criteria and return format would improve 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?

With 0% schema description coverage, the description adds brief semantics: criteria as filter dict with examples (sector, market cap, etc.) and limit as max rows. However, the criteria description is vague ('etc.') and lacks detail on supported keys or 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?

Clearly identifies the tool as screening the Beijing Stock Exchange (BSE) and distinguishes it as China's SME board. The verb 'Screen' is specific and the name differentiates from many 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?

The description names the target exchange, implying usage for BSE screening. However, it offers no explicit guidance on when to use this versus alternative tools (e.g., screen_china_a_shares) 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, so the description does not need to reiterate safety. It adds no additional behavioral details (e.g., pagination, response format), but the annotation coverage lowers the burden.

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 Args section. The purpose is front-loaded, and no extraneous information is present.

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 screening tool with two parameters and no output schema, the description covers purpose and parameter semantics adequately. It could mention return type or behavior on no results, but annotations partially fill gaps.

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 adds substantial value by explaining the criteria as 'filter dict (sector, market cap, P/E, etc.)' and limit as 'max rows to return'. This compensates for the lack of schema documentation.

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 is for screening ChiNext stocks, describing it as 'China's Nasdaq-equivalent for growth companies'. This distinctly differentiates it 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?

The description lists parameters but provides no guidance on when to use this tool versus other China screen tools (e.g., screen_china_a_shares). No exclusionary criteria or alternative recommendations 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=true and openWorldHint=true, so the description adds limited behavioral context beyond stating the market focus (hard-tech & biotech). It does not contradict annotations but also does not elaborate on side effects, permissions, or response 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 highly concise: one line for purpose followed by a docstring-style parameter list. Every word adds value, with no redundancy. Front-loaded with the market name for quick identification.

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 parameters, no output schema, read-only annotations), the description sufficiently covers the what and how. It lacks details on return format or pagination, but these are common across sibling tools and may be inferred.

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 both parameters: criteria is a dict of filters with an example, and limit is max rows to return. This adds significant meaning beyond the generic schema, though it could provide more filter options or 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 screens China's STAR Market for hard-tech and biotech IPOs, distinguishing it from siblings that screen other markets (e.g., screen_china_a_shares). The verb 'Screen' combined with the specific market name leaves no ambiguity about the tool's 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?

No guidance is provided on when to use this tool versus alternatives like screen_china_a_shares or screen_china_chinext. The sibling list is present but no criteria for selection, which is essential given multiple China-specific screening 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 and openWorldHint. The description adds minimal behavioral details beyond the purpose (examples of criteria), but does not elaborate on data freshness, pagination, or other 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 succinct with two sentences plus a clear args list. It front-loads the purpose and contains 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?

There is no output schema, and the description does not specify return values or output format. The criteria parameter lacks detailed supported keys. Given the tool is part of a suite, the description is 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?

Schema description coverage is 0%, so the description compensates by explaining criteria as a filter dict with examples (sector, market cap, P/E) and limit as max rows. While brief, it adds meaningful context 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 screens Chinese ADRs listed on US exchanges and gives specific examples like Alibaba, JD, PDD, NIO, which distinguishes it from sibling tools 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?

The description provides context for when to use this tool (for Chinese ADRs on US exchanges) through its purpose and examples, but does not explicitly mention when not to use it 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 declare readOnlyHint and openWorldHint, which the description does not contradict. Description adds minimal behavioral context (e.g., 'filter dict', 'max rows'), but doesn't elaborate on rate limits or other traits 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?

Two-line description with a title and argument list; every sentence adds value. Front-loaded, no 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?

Covers main purpose and parameters adequately given the tool's simplicity. Could mention return format or pagination, but not critical. Annotations cover safety and open-world assumptions.

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 adds basic meaning to parameters: 'criteria: filter dict (sector, market cap, P/E, etc.)' and 'limit: max rows to return'. Compensates partially but still lacks detail on valid criteria keys or value formats.

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?

Explicitly states 'Screen Xetra / Deutsche Börse' and lists specific indices (DAX 40, MDAX, etc.), clearly identifying the resource and action. Distinguishes from sibling tools by being country- and exchange-specific.

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?

Implies usage for German indices but provides no explicit guidance on when to use this vs. alternatives, nor any when-not or prerequisite 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 already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description does not add additional behavioral traits like rate limits, authentication needs, or what happens to existing data. It merely restates the purpose and args, so a 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 extremely concise: one line for purpose, two lines for args. It is front-loaded with the main action and contains no unnecessary words. 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 complexity of a screening tool, the description covers purpose, segments, and args adequately. It lacks details about the return format, but annotations (readOnlyHint, openWorldHint) and common expectations for a screening tool partially fill the gap. Overall, it is sufficiently complete 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 description coverage is 0%, but the description compensates by explaining that 'criteria' is a filter dict with examples (industry, market cap, P/E, dividend yield) and that 'limit' is max rows. This adds meaningful guidance beyond the raw schema, though not exhaustive.

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, specifying the three segments (Hang Seng, Mainboard, GEM). This makes the purpose clear and distinguishes it 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?

The description provides clear context that this tool is for screening HK stocks, but it does not explicitly state when not to use it or suggest alternatives. The context of sibling tool names (e.g., screen_us_finviz) implies the usage scope, which earns a 4.

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's behavioral contribution is minimal. It adds context about criteria fields but doesn't disclose any additional constraints, error handling, or mutability 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?

Extremely concise: two lines of purpose plus a two-line Args section. No wasted words, purpose front-loaded, and structure readable.

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 simple parameters, the description covers the tool's purpose and parameter functionality. However, it could be more complete by specifying output format (e.g., list of stocks) or any pagination, but overall sufficient for selection.

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 must compensate. It adds meaning by explaining 'criteria' as a filter dict with examples (sector, market cap, P/E) and 'limit' as max rows, which the schema alone does not provide.

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 'Screen' and resource 'India's National Stock Exchange (NSE)' including specific indices (Nifty 50, Nifty Bank, full universe), distinguishing it from sibling tools 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?

The description implies usage for screening Indian NSE data, with context signals showing 24 sibling tools for different markets, but lacks explicit when-to-use vs alternatives 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 already indicate readOnlyHint and openWorldHint. The description adds that it returns screening results, and the parameter 'limit' is described as max rows. No contradictions or missing key behaviors.

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, front-loaded with the main purpose, and includes a clear, structured list of parameters. 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?

For a simple screening tool with two optional parameters and no output schema, the description covers purpose and parameters adequately. Missing output details are not critical given the tool's straightforward nature.

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 adds essential meaning: 'criteria' is a filter dict for sector/market cap, and 'limit' is max rows. This compensates for the schema's lack of detail.

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 'Screen Indonesia Stock Exchange (IDX)' and specifies the indices LQ45, IDX30, and full Jakarta board, which 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?

While no explicit when-to-use or alternatives are given, the country and exchange name make it obvious that this tool is for screening Indonesian stocks, effectively differentiating it from sibling tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the scope of markets covered (indices and segments) but does not disclose other behavioral aspects like rate limits, data freshness, or potential size of 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 two sentences plus an Args list, front-loaded with the key exchange and market context. Every part serves a purpose 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?

The description covers purpose and parameters but lacks details about the output format or return values, which is notable given the absence of an output schema. Additionally, no error handling or typical usage scenarios are mentioned.

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 description compensates by explaining the 'criteria' parameter with examples (sector, market cap, P/B, dividend yield) and defines 'limit' as max rows. This adds 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 screens the Tokyo Stock Exchange, naming specific indices (Nikkei 225, TOPIX) and market segments (Prime/Standard/Growth). This distinguishes it from sibling tools for other exchanges, though the verb 'screen' could be more explicit about returning filtered stock 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?

Usage is implied by the exchange name: this tool is for Japan TSE data. However, there is no explicit guidance on when to use it versus alternatives, nor any mention of 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 indicate readOnlyHint and openWorldHint. The description adds that it screens stocks with criteria and limit parameters, but does not describe behavior beyond that, such as default behavior or response 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 short and front-loaded with the purpose, but the parameter documentation is embedded in a compact format. Every sentence serves a purpose, though it could be slightly 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?

The description is adequate for a simple screening tool with two optional parameters, but it lacks information about what the tool returns (e.g., stock symbols, prices). No output schema is provided, so the description should 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?

The description adds significant meaning to the parameters: it explains that 'criteria' is a filter dict with examples (industry, market cap, P/E) and 'limit' is max rows. Since schema coverage is 0%, this compensates well.

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 of major companies. It differentiates from sibling tools by specifying the exchange.

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 Korean KOSPI stocks, but provides no explicit guidance on when to use this tool versus other country-specific screeners, nor any exclusion criteria.

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, which the description does not contradict. The description adds scope (FBM KLCI, Main Market) but does not disclose additional behavioral traits like result ordering, error handling, or rate limits. It is adequate given 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?

The description is extremely concise: two lines of purpose followed by a brief arg list. Every sentence adds value with no redundancy. It is front-loaded and efficiently 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 absence of an output schema, the description should explain the return format (e.g., list of dicts, fields). It also does not mention pagination or what happens when no matches occur. The tool is simple but still lacks critical completeness for an agent 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?

The input schema has no parameter descriptions (0% coverage). The description compensates by explaining 'criteria' as a filter dict with examples (sector, market cap) and 'limit' as max rows. This adds meaning beyond the schema, though more detail on valid 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 the tool screens Bursa Malaysia specifically for FBM KLCI components and Main Market. The verb 'Screen' is appropriate and the resource is precisely identified, distinguishing it from sibling tools that 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 implies usage for Malaysian equities by naming the exchange, but it does not explicitly state when to use this tool versus alternatives (e.g., for other markets). No exclusionary guidance or conditions 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?

The description adds behavioral context beyond annotations by specifying the screened universe (IPC components and broader Mexican market). Annotations already declare readOnlyHint and openWorldHint, which are 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?

The description is concise, front-loading the purpose in the first sentence, and uses bullet-style parameter docs without redundancy. Only two sentences plus parameter lines.

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 parameters are explained, the description lacks details on output format or how results are structured. Given no output schema and only 2 optional parameters, more context on return behavior would be beneficial.

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 meaningfully explains both parameters: 'criteria: filter dict (sector, market cap, etc.)' and 'limit: max rows to return', adding functional meaning beyond schema defaults and 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 verb 'Screen' and the specific resource 'Bolsa Mexicana de Valores (BMV)', including scope 'IPC components and broader Mexican universe', which distinguishes it from sibling country-specific tools.

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 Mexican stocks via the name and market specification, but provides no explicit guidance on when to use this tool versus alternatives like screen_brazil_b3 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 and openWorldHint, so the description does not need to reiterate. The description adds that it is a screening operation, but does not disclose any additional behavioral traits such as rate limits, pagination, or return 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 short and to the point, with a clear format. It could be slightly more concise by removing the docstring formatting, but overall it 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?

Given the lack of output schema and the presence of many similar sibling tools, the description is minimally adequate. It does not describe return values or pagination, but the pattern for screening tools is likely consistent across siblings.

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 the description bears full responsibility. It explains that 'criteria' is a filter dict for sector, market cap, etc., and 'limit' is max rows, adding meaning beyond the schema's generic object and integer 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 Philippine Stock Exchange (PSE) stocks, specifying 'PSEi components and broader market', which is a specific verb and resource. The tool name and description distinguish it from siblings 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 screening Philippine stocks but does not explicitly state when to use this tool versus alternatives or provide any exclusions. Given the naming pattern, the context is clear, but no explicit guidance is 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=true and openWorldHint=true. The description adds that it screens specific sectors (e.g., banks, petrochems) but does not discuss other traits like data freshness or rate limits. It adds modest 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 argument definitions, front-loaded with the purpose. Every sentence serves a clear role with no redundancy or 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 screening tool with two parameters, the description covers purpose, parameter semantics, and examples of filters. No output schema exists, but that is acceptable given the tool's nature. It is sufficiently complete for an agent to understand 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?

With 0% schema description coverage, the description compensates by explaining criteria as a filter dict with examples (sector, market cap, dividend yield) and limit as max rows. This adds meaningful semantics beyond the schema's raw definitions, 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 the tool screens Saudi Arabia's Tadawul exchange, listing specific components like TASI, Aramco, banks, and petrochems. 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 usage for screening Saudi stocks but does not explicitly state when to use this tool vs alternatives or provide when-not-to-use guidance. The sibling context hints at exchange-specific use, but no direct comparison.

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 screens specific securities and mentions filter criteria, but lacks details on pagination, result limits, or output 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 extremely concise and front-loaded with purpose, followed by parameter explanations. 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?

The tool has no output schema, and the description does not specify return values or behavior. For a simple screening tool, it is minimally adequate but leaves gaps.

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 'criteria' as a filter dict with examples (sector, market cap, etc.) and 'limit' as max rows. Though not exhaustive, it adds meaningful context 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 it screens Singapore Exchange (SGX) for STI components and SE-Asia REIT universe, using a specific verb and resource. 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 implies usage for SGX screening but does not explicitly state when to use this tool versus alternatives (e.g., other screen_* tools). No exclusions or prerequisites are mentioned.

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 description relies on them. Adds no behavioral details beyond the sector examples. 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?

Extremely concise: one sentence for purpose plus two-line argument summary. Front-loaded with main action. 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?

Given low parameter count and no output schema, description adequately explains purpose and parameters. However, it could mention expected output format (list of stocks) for full closure.

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 carries burden. It explains criteria as a filter dict (with examples) and limit as max rows, adding basic meaning. However, lacks detail on possible filter keys or 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?

Description clearly states it screens Johannesburg Stock Exchange, listing specific sectors (Top 40, mining, financials). Differentiates from siblings by naming the exchange, though no explicit comparison.

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?

Implies use for South African stocks but provides no when-to-use or when-not-to-use guidance relative to sibling screen tools. No 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, indicating a safe, broad-scope operation. The description adds minor behavioral context by mentioning the filter criteria (industry, market cap, P/E), but does not reveal other 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?

The description is extremely concise — two lines plus brief arg definitions. No filler or redundancy. Every sentence delivers 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 and two parameters, the description covers the essential aspects: what the tool does, its focus, and the parameters. It could mention the default output format, but the name 'screen' and context from siblings imply a list. Annotations provide safety 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?

With 0% schema description coverage, the description effectively compensates by explaining that 'criteria' is a filter dict covering industry, market cap, P/E, etc., and that 'limit' is the max rows. This adds meaning beyond the schema's type/default information.

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 Taiwan Stock Exchange (TWSE) with a focus on semiconductor heavyweights like TSMC and MediaTek. This is a specific verb and resource, and it naturally distinguishes from the numerous 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?

The description implies that this tool is for screening TWSE stocks, especially semiconductors, but does not explicitly state when to use it versus alternatives like screen_us_finviz. No when-not 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 already declare readOnlyHint=true and openWorldHint=true, indicating a non-destructive read operation. The description adds scope details (SET50/SET100/full) but doesn't disclose further behavioral traits like rate limits 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?

The description is concise and front-loaded with the main purpose. The args section efficiently lists parameters. Minor improvement could be formatting the args list for clarity, but it's still effective.

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 2 parameters, no output schema, and no enums, the description covers the tool's function and param semantics adequately but lacks information on return format, pagination, or error behavior.

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 the description must add meaning. It explains 'criteria' as a filter dict with examples (sector, market cap, dividend yield) and 'limit' as max rows. This is helpful for an open-world object 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 screens the Thailand Stock Exchange (SET) for SET50, SET100, or the full universe, distinguishing it from siblings 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?

The description implies usage for Thailand screening by name but provides no explicit when-to-use, when-not-to-use, or alternative tools. Usage context is clear from the sibling exchange-specific 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, indicating a safe read operation. The description adds context by specifying the screenable indices (BIST 100, BIST 30, full universe) without contradicting annotations. It provides adequate transparency beyond the structured fields.

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 with no redundant information. It front-loads the purpose in one sentence and then clearly defines the two arguments. Every sentence is purposeful, making it easy to quickly understand the tool's 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?

The description covers the tool's inputs well but does not describe the output format or any pagination/limitations. Given the absence of an output schema and the context of sibling screeners, the description could be slightly more complete by hinting at the return type, but it remains sufficient 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?

With 0% schema description coverage, the description fully compensates by explaining that criteria is a filter dict with examples (sector, market cap, dividend yield) and limit is 'max rows to return'. This adds substantial meaning beyond the schema's generic 'anyOf object' with additionalProperties.

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 that the tool screens Borsa Istanbul, specifically mentioning BIST 100, BIST 30, and the full Turkish universe. The verb 'screen' is specific, and the tool is distinguished from siblings by the explicit country context.

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?

While the sibling tools' naming convention implies this tool is for Turkish stocks, the description does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. Usage is implied rather than clearly guided.

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. Description adds that it screens/filters stocks based on criteria, but does not detail output format or behavior with no criteria.

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 plus args list. No fluff, 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?

Explains purpose and parameters adequately, but lacks return format, error handling, pagination details. Could improve 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%, but the description explains 'criteria' as a filter dict with example fields and 'limit' as max rows. Adds meaningful context beyond the schema's types and defaults.

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 the action 'Screen' and resource 'London Stock Exchange (LSE)' with specific indices (FTSE 100, FTSE 250, AIM). Distinguishes from sibling tools which are other country screens.

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 country-specific name and description make usage context clear for screening LSE stocks. However, no explicit guidance on when not to use or alternatives 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 behavioral context by explaining that the tool accepts a screener URL and filter codes, but does not disclose rate limits, pagination, or return 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 concise: one sentence for purpose, followed by clearly structured parameter explanations. 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?

With no output schema, the description does not specify what is returned (e.g., a list of tickers, dataframe). It adequately covers parameters and sibling context, but the missing output description is a minor gap for a tool that presumably returns data.

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 the description fully compensates by specifying that 'criteria' accepts a dict of Finviz filter codes or a 'screenerUrl', and 'limit' is max rows (default 50). Examples add significant value beyond the empty 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 screens US-listed stocks (NYSE/NASDAQ/AMEX) via Finviz with 100+ filters, distinguishing it from sibling tools 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?

The description explains the two arguments (criteria and limit) with examples, including alternative input formats like a pre-built screen URL. It lacks explicit when-not-to-use guidance but effectively communicates how to use the 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 and openWorldHint. The description adds minimal behavioral context beyond parameter descriptions. It does not explain the open world nature or any side effects, so it adds little 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 concise: two sentences covering purpose and parameter definitions. It is front-loaded and efficient 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?

For a simple screening tool with two parameters and no output schema, the description is fairly complete. It could mention the return format or pagination, but it is adequate for basic 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?

With 0% schema coverage, the description compensates by explaining 'criteria' as a filter dict with examples (sector, market cap) and 'limit' as max rows. This adds meaningful semantics, though criteria fields remain 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?

The description clearly identifies the tool as screening Vietnam's HOSE exchange, including VN30 and the full board. This is specific and distinguishes it from siblings targeting different 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 implies the tool is for Vietnam HOSE screening but does not provide explicit guidance on when to use it over siblings or when not to use it. Usage is inferred from the name and exchange mention.

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