GroundAPI

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

No annotations are provided, so the description carries full disclosure burden. While 'Query' implies read-only behavior, the description fails to state safety characteristics explicitly, explain default behaviors when no parameters are provided, or describe error conditions (e.g., invalid fund codes).

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 one-line summary followed by three bulleted examples. Every sentence earns its place. However, given the lack of schema documentation, the extreme brevity leaves critical gaps in parameter coverage.

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 three primary workflows but leaves gaps regarding parameter interactions (can search and ranking be combined?) and the two undocumented parameters. Since an output schema exists, return values need not be explained, but behavioral constraints and complete parameter semantics are 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?

With 0% schema description coverage, the description partially compensates by illustrating four parameters (keyword, code, sort_by, limit) through concrete examples. However, it completely omits documentation for 'order' and 'fund_type' parameters and fails to enumerate valid values for sort_by (only showing 'return_1y' when 'perf_ytd' is the 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 queries fund data (specific resource) and enumerates three distinct operations: search, detail, and ranking. It distinguishes from siblings like finance_stock and finance_market by focusing specifically on funds (mutual funds/ETFs).

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 three examples implicitly guide usage by showing when to use keyword (search) vs code (detail) vs sort_by (ranking). However, it lacks explicit guidance on when NOT to use this versus siblings (e.g., finance_stock_screen) or whether parameters can be combined.

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?

With no annotations provided, the description carries full burden. It successfully discloses behavioral variations (what data is returned in each mode: indices, breadth, volume, industry valuation map), but lacks safety info like rate limits, caching, or auth requirements. 'Get' implies read-only 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?

Well-structured with a clear opening statement followed by bulleted examples. Each line efficiently demonstrates a specific usage pattern. The examples are necessary given the lack of schema descriptions, and there's minimal redundant 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?

Adequate coverage of primary use cases given the tool's multi-mode complexity and presence of output schema. However, gaps remain for undocumented parameters (date, type, limit, sort_by) and lack of cross-tool guidance, making it minimally viable rather than 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 has 0% description coverage. The description compensates by demonstrating usage of 'include' and 'sector' parameters through concrete examples, but leaves 4/6 parameters (date, type, limit, sort_by) completely undocumented with no semantic guidance.

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 'Get market data' with specific resource scope (indices, sectors, macro, funds). It implicitly distinguishes from siblings like finance_fund and finance_stock by emphasizing broad market overview capabilities versus specific instrument queries.

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 clear usage patterns for different modes (when to use include='sectors' vs 'funds' vs sector='name'), but lacks explicit guidance on when to use sibling tools (finance_fund vs include='funds') or when not to use this 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?

Discloses critical behavioral constraint that 'Either keyword or symbol is required' which compensates for the schema marking zero parameters as required, and explains the different data returned by each mode (current price, PE, PB for quotes; trading days for history).

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?

Efficiently structured with a single summary sentence followed by concrete examples in bullet points and a constraint note; every line provides actionable guidance 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?

Comprehensive coverage of the tool's multi-mode functionality and parameter interactions given the complexity and lack of schema documentation; adequately complete since output schema handles return value documentation.

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 providing usage examples that explain the semantics of keyword, symbol, date, days, and include parameters, though it omits explanation of the limit 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?

States 'Query A-share stock data' with specific verb and resource, clearly distinguishing from sibling tools like finance_fund (funds) and finance_stock_screen (screening) by focusing on individual stock queries and historical data retrieval.

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 excellent internal usage guidance through explicit examples showing when to use search mode (keyword) versus quote mode (symbol) versus historical mode (days), though it does not explicitly name sibling tools as 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully explains the optional nature of filters and distinguishes ranking vs. filtering modes. However, it lacks disclosure of default sorting behavior (only shown in example), rate limits, data freshness guarantees, or what constitutes the 'simple ranking' beyond the example given.

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?

Excellent structure with zero waste. Front-loaded purpose statement followed immediately by two concrete, contrasting examples that demonstrate the dual usage patterns. Final sentence clarifies optional parameter behavior. Every sentence earns its place with high information density.

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 presence of an output schema, the description appropriately omits return value details. However, with 10 parameters and 0% schema coverage, the description is incomplete—it demonstrates only 40% of parameters via examples and provides no guidance on valid values for enums (e.g., sort_by options, order values). Adequate for basic usage but insufficient for the tool's full capability.

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?

Critical gap: schema description coverage is 0% for all 10 parameters. The description only illustrates 4 parameters through examples (sort_by, limit, industry, pe_max) while leaving 6 parameters completely undocumented (order, pb_max, pe_min, max_market_cap, min_market_cap, min_dividend_yield). With zero schema coverage, the description fails to compensate adequately for the undocumented parameters.

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 dual purpose: 'Screen stocks by criteria or get top/bottom rankings.' It uses specific verbs (screen, get) and identifies the resource (stocks). While it distinguishes implicitly from sibling tools like finance_stock (likely for specific stock lookup) through the screening/ranking focus, it doesn't explicitly contrast with alternatives.

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 clear usage patterns through concrete examples showing the two primary modes: ranking (top gainers) versus filtering (semiconductor stocks with PE constraints). Explicitly states 'All filter params are optional' and explains behavior 'With no filters, returns a simple ranking,' giving agents clear guidance on when to use which 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?

With no annotations provided, the description carries full burden. It adds parameter constraints (category options, limit range 1-50) and notes 'latest' implies temporal freshness, but omits safety profile (read-only/destructive), rate limits, or data sources.

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?

Highly efficient two-sentence structure. Front-loaded with purpose, followed by parameter specifications. No redundant or wasteful 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?

Adequate for a simple 2-parameter tool with output schema present (no return value explanation needed). Parameter documentation is complete, but usage context regarding sibling differentiation is 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?

Excellent compensation for 0% schema description coverage. Documents valid category values (finance/general/tech/sports/...), limit bounds (1-50), and default values for both parameters, which the schema lacks entirely.

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?

States specific action ('Get') and resource ('latest news headlines'), but fails to distinguish from sibling tools like info_search or info_scrape which likely also retrieve information.

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 no guidance on when to use this tool versus alternatives (e.g., info_search for general queries, finance_stock for specific financial data). No prerequisites or exclusions 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?

With no annotations provided, the description carries the full burden. It successfully discloses the output format conversion (markdown), but omits other behavioral traits such as JavaScript rendering capabilities, timeout behavior, redirect handling, or error responses (404s, paywalls).

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 optimally concise with two efficient sentences: the first establishes the operation and output format, the second documents the parameter. Zero redundancy and well-structured for quick comprehension.

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 single-parameter tool with an existing output schema, the description covers the essential contract: input (URL), operation (scrape), and output format (markdown). It appropriately delegates detailed return value documentation to the output schema, though it could mention error handling scenarios.

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?

Given 0% schema description coverage, the description compensates by explicitly documenting the 'url' parameter as 'the webpage URL to scrape.' This adds necessary meaning beyond the schema's bare 'type: string,' though it lacks format examples or validation 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 specific action (read/scrape), resource (webpage), and output format (markdown). It effectively distinguishes this tool from siblings like info_search (which likely searches) and info_news (which likely retrieves news) by specifying direct URL-based scraping.

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 like info_search or info_news. It lacks explicit when-to-use criteria, prerequisites (e.g., valid URL format), 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes the return payload structure (titles, links, snippets) and lists valid values for the recency filter. However, it fails to mention authentication requirements, rate limiting, caching behavior, or whether the operation is read-only/idempotent.

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 optimally concise with two high-density sentences. The first sentence establishes purpose and return type; the second documents all parameters. There is no redundant text, and information is front-loaded effectively.

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 tool with simple scalar parameters and an existing output schema (which handles return value documentation), the description is sufficiently complete. It successfully documents all parameters that the schema leaves undescribed. A perfect score would require addressing behavioral constraints like rate limits.

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?

Given 0% schema description coverage, the description effectively compensates by documenting all three parameters inline: query (search keywords), count (1-50 range), and recency (valid enum values). It provides sufficient semantic meaning for an agent to use the parameters correctly, though it lacks examples or format nuances.

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 performs a web search and specifies the return format (titles, links, snippets). However, it does not explicitly differentiate from the sibling tool 'info_news' (which likely searches news specifically), leaving some ambiguity about when to choose this over specialized search 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 provides no guidance on when to use this tool versus alternatives like 'info_news' (news-specific search) or 'info_scrape' (URL-based extraction). It omits prerequisites, rate limits, or conditions where this tool would be inappropriate.

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?

No annotations provided, so description carries full burden. It successfully discloses the default behavior (defaults to caller IP when omitted), but lacks other behavioral traits like caching, privacy implications, or rate limiting.

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-sentence structure: first states purpose, second documents the parameter. No redundant words; 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?

Adequate for a single-parameter tool with an output schema (which handles return value documentation). However, with 0% schema coverage and no annotations, the description could strengthen contextual completeness by mentioning data freshness or privacy considerations.

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%, requiring description to compensate. It successfully documents the single parameter 'address' as an 'IP address' and clarifies its default behavior, adding essential semantics absent from 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?

States specific action ('Get') and resource ('IP geolocation info'). While clear, it does not explicitly differentiate from sibling tools like life_weather or life_logistics, though the distinction is implicit via the tool name.

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 no guidance on when to use this tool versus alternatives (e.g., when to prefer this over info_search for IP data). No prerequisites, rate limit warnings, or exclusion criteria 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?

With no annotations provided, the description carries full behavioral burden. It discloses the auto-detection behavior for the company parameter, but fails to indicate if this is a safe read-only operation, mentions rate limits, or describes error handling for invalid tracking numbers.

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 with three efficient segments: purpose statement followed by inline parameter definitions. No wasted words; every clause provides necessary information not found in the schema.

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 2-parameter tool with an output schema present. The description covers the essential functionality and parameters, though it could briefly mention what tracking information is returned (e.g., location, status history).

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?

Excellent compensation for 0% schema description coverage. The description explicitly defines 'number' as the tracking number and 'company' as the courier company code, including the behavioral note that company is 'auto-detected if omitted'.

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?

States a clear verb-resource combination ('Track a courier package') that distinguishes from finance and info siblings, though it could be more precise about whether it retrieves current status vs. initiates tracking.

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 no guidance on when to select this tool versus alternatives (e.g., when to use this versus other life tools or when tracking is appropriate). Only includes parameter-level guidance about auto-detection.

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?

With no annotations provided, the description carries the full burden. It discloses the optional nature of the 7-day forecast (behavioral trait) but omits other behavioral details such as units of measurement, handling of invalid locations, or whether the operation is read-only (though implied by 'Get').

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 the purpose front-loaded in the first sentence, followed by parameter documentation. It contains no redundant text, though the parameter documentation is compressed into a single block rather than structured as distinct fields.

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 tool with three simple parameters and an output schema (which absolves the description from detailing return values), the description is nearly adequate. However, it has a clear gap in failing to specify that at least one location parameter (city or location) must be provided despite both having default values in the 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?

Given 0% schema description coverage, the description compensates effectively by documenting all three parameters: providing an example for city ('北京'), format hint for location ('lat,lng'), and semantic meaning for forecast ('include 7-day forecast'). It does not fully compensate for missing constraint logic (e.g., mutual exclusivity or requirement of at least one location 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 'Get[s] weather data: current conditions and optional 7-day forecast,' providing a specific verb and resource. While it does not explicitly contrast with sibling tools (finance, news, logistics), the domain is sufficiently distinct that the purpose is unambiguous.

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, nor does it specify prerequisites such as requiring at least one location identifier (city or location) since both parameters technically have default values of empty string in the schema.

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