TWSE MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct, targeting specific data categories like company financials, market statistics, or broker information. However, there is some overlap between company-specific tools (e.g., get_company_balance_sheet vs. get_public_company_balance_sheet) and between similar time-period tools (e.g., get_block_trades_daily/monthly/yearly), which could cause minor confusion. The descriptions help differentiate, but the sheer volume increases the risk of misselection.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, all using snake_case with 'get_' as the prefix. The naming is predictable and systematic, making it easy to understand the purpose of each tool at a glance. There are no deviations in naming conventions across the 128 tools.
Tool Count2/5
With 128 tools, the count is excessive for a single server, even for a comprehensive financial data provider. This creates a heavy and overwhelming surface that will be difficult for agents to navigate efficiently. A more modular approach with focused servers (e.g., company data, market stats, broker info) would be more appropriate.
Completeness5/5
The tool set provides exceptionally complete coverage of the TWSE domain, including company profiles, financials, governance, market indices, trading statistics, broker data, and regulatory information. There are no obvious gaps; it supports extensive querying across all relevant aspects of the Taiwan stock exchange, enabling comprehensive agent workflows without dead ends.
Average 3.3/5 across 128 of 128 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 18 of 19 community issues answered or closed in the last 6 months
- 36 commits in the last 12 weeks
- Last stable release on July 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what data is retrieved, without mentioning any traits like read-only nature, potential rate limits, authentication needs, data freshness, or output format. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks front-loaded critical information and does not earn its place by adding value beyond the tool name. While not verbose, it fails to provide necessary context, making it inefficient in communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data tools and the absence of annotations and output schema, the description is incomplete. It does not explain what 'redemption data' includes, how it is structured, or any behavioral aspects. For a tool in a server with many siblings, more detail is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get central depository bond redemption data' restates the tool name with minimal elaboration, making it a tautology. It specifies the resource ('central depository bond redemption data') but lacks a clear, distinct verb beyond 'get', and does not differentiate from siblings like 'get_dividend_rights_schedule' or 'get_bond_redemption_schedule' (if they existed), which might offer similar financial data. The purpose is vague about what 'redemption data' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. With many sibling tools focused on financial, trading, and company data, there is no indication of context, prerequisites, or exclusions. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does, without mentioning any behavioral traits like data freshness, rate limits, authentication requirements, error conditions, or what the output contains. This leaves the agent with insufficient information to use the tool effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial analysis tool with no annotations) and the presence of an output schema (which helps), the description is incomplete. It lacks behavioral context, usage differentiation, and sufficient parameter guidance, making it inadequate for an agent to confidently invoke the tool without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema. It specifies that the 'code' parameter is a 'stock code' for a 'listed company', which provides context not in the schema (which has 0% description coverage). However, it doesn't clarify format (e.g., ticker symbol, ISIN), validation rules, or examples, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get profitability analysis') and target resource ('for a specific listed company based on its stock code'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_company_profitability_analysis_summary' or other company-specific tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools focused on company data (e.g., 'get_company_balance_sheet', 'get_company_income_statement'), there's no indication of how profitability analysis differs or when it's preferred over other financial tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation ('get') but lacks behavioral details such as data sources, update frequency, rate limits, or error conditions. The description is minimal and does not disclose any traits beyond the basic action, which is insufficient for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it is front-loaded but under-specified—while concise, it lacks necessary detail for clarity, slightly reducing its effectiveness despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name (involving stock price changes) and the lack of annotations, output schema, and parameters, the description is incomplete. It does not explain what 'range' entails, the return format, or any constraints, making it inadequate for the agent to understand the tool's behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate since none exist. It adds no semantic value beyond the schema, but with zero parameters, the baseline is 4 as the description need not compensate for missing param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get stock price increase/decrease range' states a vague purpose—it's unclear what 'range' means (e.g., time period, percentage range, or price range) and lacks specificity about the resource (e.g., which stocks, market). It distinguishes from siblings by focusing on price changes, but the verb 'get' is generic, and the scope is not clearly defined compared to tools like 'get_stock_daily_trading' or 'get_market_gain_loss_statistics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to stock data (e.g., 'get_stock_daily_trading', 'get_market_gain_loss_statistics'), the description offers no context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify whether it returns all brokers, requires authentication, has rate limits, or details the format of returned information. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool with no parameters, front-loading the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It doesn't clarify what 'basic information' includes, how results are structured, or if there are any limitations (e.g., pagination), leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no filtering or selection criteria are needed, aligning with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get basic information for brokers' states a clear verb ('Get') and resource ('brokers'), but it's vague about what 'basic information' entails. It distinguishes from siblings by focusing on brokers rather than companies or markets, but lacks specificity about the scope of information returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_broker_branch_info' or 'get_broker_headquarters_info'. The description doesn't mention prerequisites, exclusions, or contextual cues for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get electronic trading statistics', implying a read-only operation, but doesn't specify any behavioral traits such as data freshness, rate limits, authentication needs, or output format. This is a significant gap for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name (statistics retrieval) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'electronic trading statistics' includes, how data is returned, or any constraints, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. The baseline for 0 parameters is 4, as the description needn't compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get electronic trading statistics' clearly states the verb ('Get') and resource ('electronic trading statistics'), providing a basic purpose. However, it lacks specificity about what 'electronic trading statistics' entails (e.g., time period, broker scope, metrics) and doesn't distinguish it from sibling tools like 'get_real_time_trading_stats' or 'get_daily_market_trading_info', making it vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to trading statistics (e.g., 'get_real_time_trading_stats', 'get_daily_market_trading_info'), the description offers no context, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get basic information' which implies a read-only operation, but doesn't disclose behavioral traits such as whether it requires authentication, rate limits, what 'basic information' includes (e.g., address, contact details), or if it returns structured data. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (simple read operation), no annotations, no output schema, and 0 parameters, the description is incomplete. It doesn't explain what 'basic information' includes, the return format, or any behavioral context. For a tool with no structured data to rely on, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (empty schema). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for no parameters. It doesn't compensate for any gaps since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get basic information of broker headquarters' clearly states the verb ('Get') and resource ('broker headquarters'), but it's vague about what 'basic information' entails. It distinguishes from siblings like 'get_broker_basic_info' and 'get_broker_branch_info' by specifying 'headquarters', but doesn't clarify how this differs in scope or content from those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_broker_basic_info' and 'get_broker_branch_info', the description doesn't indicate whether this is for headquarters-specific data, when it's preferred over general broker info, or any prerequisites. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get' implies a read operation, but lacks details on permissions, rate limits, data freshness, or output format. For a tool with zero annotation coverage, this minimal description fails to provide necessary behavioral context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data and lack of annotations or output schema, the description is insufficient. It does not explain what 'overview' includes, how data is returned, or any behavioral traits. For a tool in a domain with many siblings, more context is needed to ensure the agent can use it correctly without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate since none exist. However, it could hint at implicit filtering (e.g., by broker or date), but given the schema's completeness, a baseline of 4 is warranted as it aligns with the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get income and expenditure overview for brokers' clearly states the verb ('Get') and resource ('income and expenditure overview for brokers'), providing a basic purpose. However, it lacks specificity about what 'overview' entails (e.g., aggregated data, time period, format) and does not distinguish it from sibling tools like 'get_broker_monthly_statements' or 'get_broker_basic_info', leaving ambiguity about scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to brokers (e.g., 'get_broker_monthly_statements', 'get_broker_basic_info'), the description offers no context on prerequisites, timing, or comparative use cases, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but does not specify data format, potential errors (e.g., invalid stock codes), rate limits, or authentication needs. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary details. It is front-loaded and avoids redundancy, though it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely defines return values), the description's minimalism is somewhat acceptable. However, with no annotations, low schema coverage, and a sibling tool that may overlap, the description lacks sufficient context for reliable use, such as error handling or data scope clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'code' undocumented. The description adds some meaning by specifying 'stock code', clarifying it's for a listed company, but does not detail format (e.g., ticker symbol, numeric code) or validation rules. This provides basic context but falls short of fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('obtain') and resource ('anti-competitive litigation losses information for a listed company'), making the purpose specific and understandable. However, it does not explicitly differentiate from its sibling 'get_companies_with_anticompetitive_losses', which appears to be a broader list tool, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling 'get_companies_with_anticompetitive_losses' or other company data tools. It lacks context on prerequisites, limitations, or typical use cases, offering minimal direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves emissions information but does not mention any behavioral traits like data sources, update frequency, rate limits, or error handling. This leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary details. It is front-loaded and appropriately sized, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) and no annotations, the description is minimally adequate. However, for a tool with potential complexity in emissions data retrieval, it lacks details on data scope, formats, or limitations, making it incomplete for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by specifying that the parameter 'code' is a 'stock code' for a listed company, which clarifies beyond the schema's generic 'Code' title. However, with 0% schema description coverage and only one parameter, this provides basic but not comprehensive value, aligning with the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('greenhouse gas emissions information for a listed company'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools, which include various company data retrieval tools, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other company data tools in the sibling list. It lacks context on prerequisites, exclusions, or specific scenarios for usage, offering only basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions obtaining violations but does not specify aspects like data freshness, rate limits, authentication needs, or what the output entails (e.g., types of violations, time ranges). This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the key action and resource, making it easy to parse, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (focused on regulatory violations), no annotations, and an output schema present (which may cover return values), the description is minimally adequate. It specifies the input and purpose but lacks details on behavioral traits and usage context, making it incomplete for full agent understanding without relying on the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description adds meaning by clarifying that 'code' refers to a 'stock code' for a listed company. However, it does not provide details on format (e.g., ticker symbol conventions) or examples, so while it compensates somewhat, it does not fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('obtain') and the specific resource ('information disclosure and shareholder meeting regulation violations for a listed company'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get_company_sec_regulatory_penalties' or 'get_company_shareholder_meeting_announcements', which might overlap in regulatory contexts, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying the input ('based on its stock code'), but it does not indicate when to use this tool versus alternatives, such as other company violation or regulatory tools in the sibling list. No exclusions or prerequisites are mentioned, leaving usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'simplified' earnings forecast achievement, hinting at a high-level or aggregated output, but doesn't detail what 'simplified' entails, such as data granularity, time range, or calculation method. It lacks information on permissions, rate limits, error handling, or response format, which is critical for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy and waste, making it easy to parse. However, it could be slightly more structured by separating usage context or behavioral notes, but it remains appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with low schema coverage and no annotations, the description provides basic purpose and parameter context but lacks depth. The presence of an output schema mitigates the need to explain return values, but the description doesn't address behavioral aspects like data sources, update frequency, or error cases. For a financial data tool with many siblings, more guidance on differentiation and usage would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic context. The description adds value by specifying that 'code' refers to a 'stock code' for a 'listed company,' clarifying its purpose beyond a generic string. However, it doesn't explain format (e.g., ticker symbol, ISIN), validation rules, or examples, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('quarterly earnings forecast achievement (simplified) for a listed company'), specifying it's based on stock code. It distinguishes itself from siblings by focusing on earnings forecast achievement, unlike tools for balance sheets, trading info, or governance data. However, it doesn't explicitly contrast with a specific sibling tool for similar financial metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, stating it's for 'a listed company based on its stock code,' which implies usage for stock-traded entities but doesn't specify when to use this tool versus alternatives like 'get_company_eps_statistics' or 'get_company_profitability_analysis.' No exclusions, prerequisites, or explicit alternatives are mentioned, leaving the agent with little context for tool selection among financial data siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is 'Get,' implying a read-only operation, but does not specify aspects like data format, pagination, rate limits, authentication needs, or error handling. This leaves significant gaps in understanding the tool's behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information without unnecessary words. It is appropriately sized for the tool's complexity, though it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations, 0% schema description coverage, and a single parameter, the description provides only basic purpose and parameter context. It is minimally adequate but lacks depth in behavioral and usage details, making it incomplete for optimal agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by stock code,' which aligns with the single parameter 'code' in the input schema. However, with 0% schema description coverage, the schema provides no details about the parameter. The description adds minimal semantics by indicating the parameter is a stock code, but it does not explain format, validation, or examples, resulting in a baseline score due to the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'comprehensive shareholder meeting announcements for a specific company by stock code,' making the purpose explicit. However, it does not differentiate from its sibling 'get_company_shareholder_meeting_announcements' (without '_by_code'), which might handle similar data but potentially with different parameters or scope, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other sibling tools for shareholder meetings or company data. It lacks explicit context, prerequisites, or exclusions, offering only a basic usage scenario without comparative information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states it 'gets information,' implying a read-only operation, but does not specify any behavioral traits such as data format, potential rate limits, authentication needs, or what constitutes 'shareholder exercise of proposal rights' (e.g., historical data, current status). This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get information about shareholder exercise of proposal rights.' It is front-loaded and wastes no words, making it easy to parse quickly. However, it could be slightly more informative without losing conciseness, such as by specifying the type of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description does not need to explain parameters or return values. However, it lacks context about the tool's scope, data source, or any limitations, which could be important for an AI agent to use it correctly. The description is minimal but meets basic requirements due to the simple nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add any parameter information, which is appropriate since there are no parameters to describe. Given the baseline for 0 parameters is 4, this score reflects that the description does not need to compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get information about shareholder exercise of proposal rights' which provides a clear verb ('Get information') and resource ('shareholder exercise of proposal rights'), making the purpose understandable. However, it lacks specificity about what type of information is retrieved (e.g., statistics, details, history) and does not distinguish it from sibling tools like 'get_company_shareholder_meeting_announcements' or 'get_companies_cumulative_voting', which might relate to similar shareholder activities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or exclusions, and with many sibling tools focused on company and shareholder data, there is no indication of how this tool differs or when it is the appropriate choice, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'obtains' information, implying a read operation, but doesn't specify if it's real-time or historical, what format the output takes, any rate limits, authentication needs, or error conditions. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It could be slightly more structured by including usage context, but it avoids redundancy and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and a simple input schema with one parameter, the description is minimally complete. It states what the tool does but lacks behavioral details and usage guidelines, making it adequate but with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that the 'code' parameter is a 'stock code', which provides meaning beyond the schema's generic 'Code' title and string type. However, with 0% schema description coverage and only one parameter, this minimal addition doesn't fully compensate for the lack of schema details, meeting the baseline for adequate but limited value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and the resource 'waste management information for a listed company', specifying it's based on stock code. It distinguishes from many siblings focused on other company data (e.g., financials, governance), but doesn't explicitly differentiate from similar tools like get_company_water_management or get_company_energy_management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., valid stock codes), exclusions, or compare to similar tools like get_company_water_management, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits like rate limits, authentication needs, data freshness, or what 'targets and statistics' entail. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence: 'Get daily day trading targets and statistics.' It's front-loaded and wastes no words, making it easy to parse. However, it could be slightly more informative without losing conciseness, such as specifying the source or scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and many sibling tools, it lacks context on behavior, differentiation, and usage, making it incomplete for an agent to fully leverage the tool in a complex environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, earning a baseline score of 4 for adequately handling the lack of inputs without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get daily day trading targets and statistics' clearly states the verb ('Get') and resource ('daily day trading targets and statistics'), making the purpose understandable. However, it doesn't differentiate from siblings like 'get_daily_market_trading_info' or 'get_real_time_trading_stats', leaving ambiguity about what specifically distinguishes this tool from other market data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to trading data (e.g., 'get_daily_market_trading_info', 'get_real_time_trading_stats'), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what data is returned but doesn't describe important behavioral aspects like whether this is a read-only operation, what time period is covered, whether there are rate limits, authentication requirements, error conditions, or how the data is structured in the output. The description is minimal and leaves critical behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the key information about what data is obtained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description's main job is to explain purpose and usage. However, with no annotations and minimal parameter documentation, the description doesn't provide enough context about behavioral aspects or usage guidelines. It's adequate for understanding what the tool does at a high level but incomplete for proper agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It mentions 'stock code' which corresponds to the 'code' parameter, but provides no additional semantic context about what format the code should be in (e.g., ticker symbol, ISIN), what validation occurs, or examples of valid values. This leaves the parameter meaningfully under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('obtain daily closing price and monthly average price') and identifies the resource ('listed company stock based on its stock code'). It distinguishes from many siblings that focus on different data types (e.g., governance, trading info, financials), though it doesn't explicitly differentiate from similar stock price tools like get_stock_daily_trading or get_stock_monthly_trading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites exist, or how it differs from sibling tools like get_stock_daily_trading or get_stock_monthly_trading that might provide overlapping or complementary data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation ('Get announcement') but does not disclose behavioral traits such as data freshness, rate limits, authentication needs, or error handling. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It is appropriately sized for a no-parameter tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and no annotations are provided, the description is minimally adequate. It states what the tool does but lacks context on output format, data scope, or usage scenarios. With an output schema, return values are covered, but more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the schema's completeness. A baseline of 4 is appropriate as the tool requires no inputs, and the description does not mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get announcement of suspended buy-sell-same-day trading targets,' which is clear but vague. It specifies the resource (announcement) and general context (suspended day trading targets) but lacks specificity about what the announcement contains or its format. It distinguishes from siblings like 'get_suspended_day_trading_history' by focusing on announcements rather than historical data, but could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, timing, or how it differs from similar tools like 'get_suspended_trading_stocks' or 'get_daily_day_trading_targets.' This leaves the agent without context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states what the tool does without details on output format, data freshness, rate limits, or authentication needs. This lack of information makes it insufficient for a tool that likely returns sensitive or complex data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, making it highly concise and front-loaded. It efficiently conveys the core purpose without redundancy or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations and a potentially complex domain (business scope changes), the description lacks context on data scope, limitations, or behavioral aspects, making it minimally adequate but incomplete for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is acceptable given the schema's completeness, but it could have clarified any implicit filters (e.g., time range). Baseline is 3, but since no parameters exist, a score of 4 reflects that the description adequately addresses the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get companies with major changes in business scope' clearly states the verb ('Get') and resource ('companies with major changes in business scope'), making the purpose understandable. However, it does not differentiate from sibling tools like 'get_companies_ownership_changes_business_scope', leaving ambiguity about what distinguishes 'major changes' from other business scope-related queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as sibling tools that also involve business scope changes. There is no mention of specific contexts, prerequisites, or exclusions, leaving the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation ('get') but doesn't disclose behavioral traits such as data freshness, rate limits, authentication needs, or what 'changes' entails (e.g., time range, threshold). The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the core purpose. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is minimally complete. However, it lacks context about what 'ownership structure changes' means, and with no annotations, it doesn't provide enough behavioral insight for effective use. It's adequate but has clear gaps in guidance and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. Baseline is 4 for 0 parameters, as no additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get companies with changes in ownership structure' clearly states the action (get) and resource (companies with ownership changes), but it's vague about what constitutes 'ownership structure changes' and doesn't distinguish from similar siblings like 'get_companies_ownership_changes_business_scope' or 'get_companies_with_business_scope_changes'. It provides basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With many sibling tools focused on company changes (e.g., business scope, ownership changes), there's no indication of context, prerequisites, or exclusions. This leaves the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation ('Get'), implying it's likely safe, but doesn't disclose any behavioral traits such as data freshness, rate limits, authentication needs, or what 'centralized market' refers to. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a tool with no parameters, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimally adequate but incomplete. It lacks details on what 'daily market trading information' entails (e.g., metrics, timeframes, format) and how it differs from siblings, which is crucial in a crowded toolset. Without annotations or output schema, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate since none exist. It adds no semantic value beyond the schema, but with zero parameters, the baseline is high as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get daily market trading information in the centralized market' which provides a clear verb ('Get') and resource ('daily market trading information'), but it's vague about what specific information is included. It doesn't distinguish itself from sibling tools like 'get_stock_daily_trading' or 'get_cross_market_trading_info' that might provide overlapping or related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools focused on trading data (e.g., 'get_stock_daily_trading', 'get_cross_market_trading_info'), the description lacks context about its specific scope or differentiation, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get') without detailing traits such as whether it's a read-only operation, requires authentication, has rate limits, or what the output entails. While 'Get' implies a read operation, it lacks specifics on data freshness, pagination, or error handling, making it insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence: 'Get stocks abnormally recommended in financial programs.' It is front-loaded with the core action and resource, with no wasted words or redundant information. This makes it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's job is simplified. It adequately states what the tool does without needing to explain parameters or return values. However, it lacks context on behavioral aspects like data sources or limitations, which could be important for a tool fetching financial data, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description does not add parameter information, which is acceptable since there are none to explain. It effectively communicates the tool's purpose without unnecessary details, aligning with the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get stocks abnormally recommended in financial programs' states a clear verb ('Get') and resource ('stocks abnormally recommended in financial programs'), providing a basic purpose. However, it lacks specificity about what 'abnormally recommended' means (e.g., based on volume, price, or other metrics) and does not differentiate from siblings like 'get_abnormal_accumulated_notice_stocks', which might overlap in concept. This makes it somewhat vague but not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it refer to sibling tools for comparison. This leaves the agent without direction on appropriate usage scenarios, relying solely on the tool name and description for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool does ('Get'), implying a read operation, but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, or what the output contains. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and an output schema exists, the description doesn't need to explain inputs or return values. However, it lacks context on usage, behavioral traits, and sibling differentiation, making it incomplete for guiding an agent effectively in a complex server with many tools. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, but it could have clarified if any implicit parameters (e.g., date defaults) exist. Baseline is 4 for zero parameters, as the schema fully covers the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get odd-lot trading quotes in the centralized market' clearly states the action ('Get') and resource ('odd-lot trading quotes'), but it's vague about scope (e.g., time range, specific market) and doesn't differentiate from siblings like 'get_daily_market_trading_info' or 'get_stock_daily_trading' that might overlap. It provides a basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to trading data (e.g., 'get_block_trades_daily', 'get_after_hours_trading'), the description doesn't specify context, exclusions, or prerequisites, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get') without detailing what 'Get' entails—e.g., whether it returns a list, the format, any rate limits, authentication needs, or data freshness. For a tool with no annotations, this minimal description fails to provide necessary behavioral context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Get recently listed companies.' It is front-loaded and wastes no words, making it easy to parse. For a simple tool with no parameters, this brevity is appropriate and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's job is reduced. However, with no annotations and many sibling tools, it lacks context on scope (e.g., timeframe for 'recently') and behavioral details. The output schema may cover return values, but the description doesn't add enough to fully guide usage in this complex sibling environment, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required or provided, making a score of 4 appropriate as it doesn't detract from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recently listed companies' clearly states the verb ('Get') and resource ('recently listed companies'), making the basic purpose understandable. However, it doesn't specify what 'recently' means (timeframe) or how this differs from sibling tools like 'get_suspended_listed_companies' or 'get_first_listed_foreign_stocks_daily', leaving the scope vague compared to more specific sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools focused on companies (e.g., 'get_suspended_listed_companies', 'get_companies_with_ownership_changes'), the description lacks any context about when this specific tool is appropriate, such as for newly listed versus other company statuses. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool does without disclosing behavioral traits like whether it's a read-only operation, requires authentication, has rate limits, or what the output format entails. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a tool with no parameters, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and no annotations are provided, the description is minimally complete. However, it lacks details on output structure or behavioral context, which could be helpful despite the output schema. It's adequate but leaves gaps in understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add parameter semantics, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get securities trading method changes in the centralized market,' which includes a verb ('Get') and resource ('securities trading method changes'). However, it's vague about what 'securities trading method changes' specifically entails compared to siblings like get_after_hours_trading or get_block_trades_daily, lacking differentiation in scope or granularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to trading and market data, there's no mention of specific contexts, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what the tool returns but doesn't cover critical aspects like whether it's a read-only operation, potential rate limits, authentication needs, or data freshness. The description lacks behavioral traits beyond the basic output structure, which is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement followed by a bulleted list of return fields. Each sentence and bullet point adds value without waste. It could be slightly more front-loaded by emphasizing the core function earlier, but overall, it's efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description provides basic completeness by stating the purpose and output fields. However, it lacks details on behavioral aspects like data sources, update frequency, or error handling, which are important for a stock data tool. The description is adequate but has clear gaps in contextual depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description appropriately doesn't discuss parameters, focusing instead on the output. This aligns with the schema's completeness, earning a high score as it avoids redundancy and correctly handles the parameter-less case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get stocks with abnormal accumulated notice counts.' It specifies the verb ('Get') and resource ('stocks with abnormal accumulated notice counts'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_today_notice_stocks' or others that might involve notices, leaving room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to stocks, notices, and trading data, there is no mention of context, prerequisites, or comparisons to tools like 'get_today_notice_stocks' or 'get_stock_daily_trading'. This lack of usage guidelines could lead to confusion in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get' which implies a read operation, but doesn't specify if it requires authentication, has rate limits, returns paginated results, or what format the statements are in. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and gets straight to the point, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by retrieving 'monthly statements' (likely financial data), no annotations, and no output schema, the description is insufficient. It doesn't explain what the statements contain, their format, time range, or how results are returned, leaving the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 for adequately handling the lack of parameters without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get monthly statements for brokers' clearly states the action (Get) and resource (monthly statements for brokers), which is specific and understandable. However, it doesn't differentiate from sibling tools like 'get_broker_basic_info' or 'get_broker_income_expenditure' that also retrieve broker-related data, so it doesn't fully distinguish its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for broker data (e.g., 'get_broker_basic_info', 'get_broker_income_expenditure'), it lacks context on specific use cases, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does without mentioning any behavioral traits such as whether it's a read-only operation, if it requires authentication, rate limits, or what the output format might be. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized for its simple function, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'personnel numbers' entail (e.g., counts, details), how the data is structured, or any limitations, which is insufficient for an agent to understand the tool's behavior and output fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents that no inputs are required. The description does not add parameter details beyond this, which is acceptable since there are no parameters to explain, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('personnel numbers by service type for brokers'), making it easy to understand what it does. However, it does not explicitly differentiate from sibling tools like 'get_broker_basic_info' or 'get_broker_gender_statistics', which might also relate to broker data, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools focused on brokers and companies, there is no indication of context, prerequisites, or exclusions, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'obtain' which implies a read operation, but doesn't disclose behavioral traits like data format, potential errors (e.g., invalid code), rate limits, or authentication needs. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently conveys the essential information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, 0% schema coverage, no annotations, and an output schema exists, the description is minimally complete. It covers the basic purpose but lacks details on usage, behavior, and parameter specifics, which are needed for effective tool invocation despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema. It specifies the parameter 'code' is a stock code, but with 0% schema description coverage and 1 parameter, this provides basic context. However, it doesn't detail format (e.g., ticker symbol, exchange code) or examples, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('obtain') and resource ('board information for a listed company'), specifying it's based on stock code. It doesn't differentiate from sibling tools like 'get_company_board_shareholdings' or 'get_company_governance_info', which might provide overlapping or related data, so it lacks explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., 'get_company_board_shareholdings', 'get_company_governance_info'), the description doesn't specify if this is for general board info, specific aspects, or how it differs, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Obtain') but lacks details on permissions, data freshness, rate limits, or error handling. The description doesn't contradict annotations (none exist), but it fails to provide sufficient behavioral context for safe and effective use by an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key input requirement. It avoids redundancy and is front-loaded with essential information, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely defines return values), the description's focus on purpose and input is appropriate. However, with no annotations and low schema coverage, it lacks behavioral and parametric details that would enhance completeness. The description is adequate for basic understanding but insufficient for robust agent decision-making without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that the 'code' parameter is a 'stock code' for a 'listed company', which clarifies the parameter's purpose beyond the schema's generic 'Code' title. However, it doesn't detail format constraints (e.g., length, allowed characters) or provide examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and target resource ('board members' shareholding details for a listed company'), making the purpose evident. It specifies the input parameter ('based on its stock code'), which helps understand the scope. However, it doesn't explicitly differentiate from similar sibling tools like 'get_company_board_info' or 'get_public_company_board_shareholdings', which would require more specific distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance by implying the tool is for listed companies and requires a stock code, but it doesn't specify when to use this tool versus alternatives (e.g., 'get_company_board_info' for general board info or 'get_public_company_board_shareholdings' for public companies). No explicit exclusions or prerequisites are mentioned, leaving gaps in contextual application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'obtains' information, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, response format, or whether it returns real-time or historical data. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and only one parameter, the description is minimally adequate. However, with no annotations and sibling tools covering similar ESG topics, it lacks context on scope, data recency, or differentiation, leaving room for improvement in guiding effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that the parameter 'code' is a 'stock code', which provides meaning beyond the schema's generic 'Code' title and 0% coverage. However, it doesn't specify format (e.g., ticker symbols, ISIN codes) or constraints, leaving some ambiguity. With 1 parameter and low schema coverage, this partial clarification earns a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and the resource 'climate-related management information for a listed company', specifying it's based on stock code. It distinguishes from most siblings that focus on financial, trading, or governance data, though it doesn't explicitly differentiate from other climate/ESG tools like 'get_company_greenhouse_gas_emissions' or 'get_company_energy_management'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., valid stock codes), exclusions, or compare to similar tools like 'get_company_energy_management' or 'get_company_greenhouse_gas_emissions' that might overlap in climate-related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers limited behavioral insight. It implies a read operation ('Obtain') but doesn't disclose permissions, rate limits, data freshness, or error handling. The mention of 'consolidated' hints at aggregated data, but lacks details on scope or format. For a tool with no annotations, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without redundancy. It front-loads key information ('Obtain consolidated director compensation information') and avoids unnecessary words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers the basic purpose and parameter intent, but lacks behavioral context, usage differentiation, and detailed parameter guidance. The output schema mitigates some completeness needs, but overall it's a bare-bones description for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only partially does. It mentions the parameter 'code' as 'stock code', clarifying it's for company identification, but doesn't specify format (e.g., ticker symbol, ISIN) or validation rules. With 1 parameter and low schema coverage, the description adds some meaning but leaves gaps in usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('consolidated director compensation information for a listed company'), specifying it's for a 'listed company' based on 'stock code'. It distinguishes from sibling 'get_company_director_compensation' by emphasizing 'consolidated', but doesn't explicitly contrast them. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it indicates the tool is for 'listed company' data using a 'stock code', but offers no explicit when-to-use advice, prerequisites, or alternatives. It doesn't differentiate from similar sibling tools like 'get_company_director_compensation' or 'get_company_consolidated_supervisor_compensation', leaving usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtains' information, implying a read-only operation, but does not address potential behavioral traits like data freshness, rate limits, authentication needs, error handling, or what 'consolidated' means in practice. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary details. It is front-loaded and wastes no words, making it easy to parse quickly. This exemplifies optimal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is somewhat complete for basic understanding. However, with no annotations and minimal parameter guidance, it lacks depth on behavioral aspects and usage context. It meets the minimum viable threshold but has clear gaps in providing a fully informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic value beyond the input schema, which has 0% description coverage. It mentions the parameter 'code' as a 'stock code', providing basic context, but does not elaborate on format, examples, or constraints. With one parameter and low schema coverage, the description partially compensates but remains inadequate for full clarity, aligning with the baseline for minimal parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('consolidated supervisor compensation information for a listed company'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_company_supervisor_compensation' or 'get_company_consolidated_director_compensation', which might cause confusion about what 'consolidated' entails or how it differs from non-consolidated versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying the input ('based on its stock code'), but it lacks explicit instructions on when to use this tool versus alternatives, such as distinguishing from 'get_company_supervisor_compensation' or other compensation-related tools. No context, exclusions, or prerequisites are mentioned, leaving the agent with insufficient direction for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes a read operation ('Obtain') but doesn't cover critical aspects like data freshness (e.g., real-time vs. historical), rate limits, authentication requirements, error handling, or pagination. The description is too sparse for a tool that likely accesses financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without unnecessary details. It is front-loaded and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (financial data retrieval), lack of annotations, and presence of an output schema (which reduces the need to describe return values), the description is minimally adequate. However, it misses key contextual details like data source, update frequency, or usage constraints, leaving gaps in completeness for practical agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema, which has 0% description coverage. It mentions the parameter is 'based on its stock code', but doesn't clarify the code format (e.g., ticker symbol, ISIN), validation rules, or examples. With one parameter and low schema coverage, the description only partially compensates, resulting in an adequate but incomplete understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('daily insider share transfer pre-announcements for a listed company'), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling 'get_company_daily_insider_trades_untransferred', which appears to cover a related but distinct aspect of insider trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying the input parameter ('based on its stock code'), but offers no context on when to use this tool versus alternatives like the sibling tool for untransferred trades or other company data tools. It lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('obtain') but does not specify data freshness, rate limits, authentication requirements, or error handling. The mention of 'untransferred' shares adds some context, but overall behavioral traits are inadequately covered for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality without unnecessary words. It is front-loaded with the main action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low schema description coverage, the description is moderately complete. It covers the basic purpose and parameter intent but lacks depth in usage guidelines, behavioral details, and integration with sibling tools, leaving room for improvement in contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by clarifying that the 'code' parameter refers to a 'stock code' for a listed company, which is not evident from the schema alone (0% coverage). However, it does not provide further details such as format examples (e.g., ticker symbols), validation rules, or how the code maps to the company, leaving some semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('obtain') and resource ('daily insider share transfers that have not yet been executed for a listed company'), making the purpose specific and understandable. However, it does not explicitly differentiate from its sibling 'get_company_daily_insider_trades_preannounced', which appears related but is not directly contrasted in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying the input parameter ('based on its stock code'), but offers no explicit advice on when to use this tool versus alternatives like the preannounced trades sibling or other company data tools. There is no mention of prerequisites, exclusions, or specific contexts for application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'Obtains' information, implying a read-only operation, but does not specify whether it requires authentication, has rate limits, returns historical or current data, or handles errors. This leaves significant gaps in understanding the tool's behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficient, making it easy to parse and understand quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations, low schema coverage, and multiple sibling tools, the description is minimal. It covers the basic purpose but lacks details on usage, behavior, and parameter nuances, making it only adequate for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'code' documented only as a string. The description adds minimal semantics by specifying 'stock code' as the input, which clarifies the parameter's purpose. However, it does not provide format details, examples, or constraints, resulting in a baseline score due to the schema's lack of coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('dividend distribution information of a listed company'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_dividend_rights_schedule' or others that might involve dividends, leaving room for ambiguity in a crowded sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other dividend-related tools in the sibling list. It mentions the input parameter ('stock code') but offers no context on prerequisites, timing, or exclusions, which limits its utility for an AI agent in selecting the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtains' information, implying a read-only operation, but does not clarify aspects like data freshness, rate limits, authentication needs, or error handling. For a tool with no annotations, this is a significant gap in transparency, as the agent lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core purpose and efficiently conveys the necessary information without redundancy or unnecessary detail, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations, 0% schema description coverage, and one parameter, the description is minimal. It states what the tool does but lacks context on usage, behavioral traits, or parameter details, making it incomplete for effective agent operation despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic value beyond the input schema. It mentions 'based on its stock code,' which aligns with the 'code' parameter, but with 0% schema description coverage, the schema provides no details about the parameter. The description does not explain what format the code should be in (e.g., ticker symbol, ISIN) or provide examples, leaving the parameter meaning vague. Baseline is 3 due to low coverage, but the description does not fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtain energy management information for a listed company based on its stock code.' It specifies the verb ('obtain'), resource ('energy management information'), and scope ('listed company'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'get_company_climate_management' or 'get_company_waste_management', which might overlap in environmental or sustainability data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific contexts, such as when energy management data is needed versus other company information tools. With many sibling tools available, the lack of comparative guidance leaves the agent uncertain about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Obtain' which implies a read operation, but doesn't disclose behavioral traits like data freshness, rate limits, authentication needs, or what 'by industry' entails (e.g., comparison, ranking, or raw data). This leaves significant gaps for an agent to understand how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Obtain EPS statistics by industry') and efficiently specifies the target ('for a listed company based on its stock code'). There's no wasted verbiage, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (financial data retrieval), no annotations, and an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral constraints, and parameter nuances, leaving the agent with incomplete guidance despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema. It clarifies that 'code' refers to a 'stock code' for a 'listed company', which provides context not in the schema (which has 0% description coverage). However, it doesn't explain format (e.g., ticker symbol), validation, or examples, leaving the parameter only partially documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain EPS statistics by industry') and target resource ('for a listed company based on its stock code'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_company_profitability_analysis' or 'get_stock_valuation_ratios' that might also provide financial metrics, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools offering company financial data (e.g., 'get_company_profitability_analysis', 'get_company_income_statement'), there's no indication of what makes EPS statistics by industry unique or when it's preferred over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation ('Obtain') but doesn't disclose behavioral traits like authentication needs, rate limits, response format, or whether it's idempotent. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part contributes directly to understanding the tool's function, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and an output schema exists, the description adds some value by clarifying the parameter. However, with no annotations and many sibling tools, it lacks sufficient context on usage, behavior, and differentiation, making it only minimally complete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining that 'code' refers to 'stock code' for a listed company. This clarifies the parameter's purpose beyond the bare schema. However, it doesn't detail format constraints or examples, so it only partially compensates for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and target resource ('financial report acknowledgment by supervisors for a listed company'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_company_supervisor_compensation' or 'get_company_governance_info', which might overlap in domain, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying 'based on its stock code', but offers no explicit when-to-use advice, alternatives, or exclusions compared to numerous sibling tools. Without context on when this tool is preferred over others, usage remains ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but lacks details on potential limitations like rate limits, authentication needs, error handling, or the nature of the returned data (e.g., format, completeness). This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema, the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks depth for safe and effective use, such as error scenarios or data freshness, which could be important for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds some semantic context by indicating the parameter 'code' refers to a 'stock code'. This clarifies the parameter's purpose beyond the schema's basic type definition. However, it does not provide details on format, validation, or examples, so it partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('food safety information for a listed company'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from sibling tools like 'get_company_product_quality_safety', which might cover similar domains, leaving room for ambiguity in sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying the input ('based on its stock code'), but offers no explicit advice on when to use this tool versus alternatives, such as other company-related tools in the sibling list. There is no mention of prerequisites, exclusions, or comparative contexts to aid selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'obtain' which implies a read operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, data freshness, error handling, or what 'fuel management information' entails (e.g., metrics, reports). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, resource, and key input constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and a simple input schema with 1 parameter, the description is minimally adequate. However, it lacks details on behavioral aspects (e.g., data source, limitations) and parameter nuances, making it incomplete for optimal agent use despite the output schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema only indicates a 'code' parameter of type string without description. The description adds that it's a 'stock code', providing essential context beyond the schema. However, it doesn't specify format (e.g., ticker symbol, ISIN) or examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and the resource 'fuel management information for a listed company', specifying it's based on stock code. It distinguishes from many siblings that focus on other company aspects (e.g., financials, governance), but doesn't explicitly differentiate from tools like get_company_energy_management or get_company_waste_management that might overlap in environmental/management themes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., valid stock codes), exclusions, or compare to similar tools like get_company_energy_management, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'obtain' which implies a read operation, but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, or what 'corporate governance information' entails (e.g., board details, regulations). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action and resource, no wasted words. It efficiently conveys the purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, but an output schema exists (so return values are documented elsewhere), the description is incomplete. It covers basic purpose but lacks behavioral context, parameter details, and usage guidelines, making it adequate only with reliance on structured fields like the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that the 'code' parameter is a 'stock code' for a 'listed company', which provides context beyond the schema's generic 'Code' title and 0% coverage. However, it doesn't specify format (e.g., ticker symbol, ISIN) or examples, leaving gaps. With one parameter and low schema coverage, this is minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and the resource 'corporate governance information for a listed company', specifying it's based on a stock code. It distinguishes from siblings by focusing on governance info rather than financials, news, or other company data, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_company_profile or get_company_board_info, which might overlap. The description implies usage for governance info but lacks explicit context or exclusions, leaving the agent to infer based on sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('obtain') but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, data freshness, or what happens with invalid codes. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and only one parameter, the description is minimally complete. However, with no annotations and a simple but potentially critical operation (fetching regulations), it could benefit from more context on usage constraints or data scope to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'code' parameter is a 'stock code' for a 'listed company', which clarifies its purpose beyond the schema's generic 'Code' title. However, with 0% schema description coverage and only one parameter, this is adequate but not comprehensive (e.g., no format examples or validation rules).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('obtain') and resource ('corporate governance regulations and rules') with specific targeting ('for a listed company based on its stock code'). It distinguishes from many siblings that focus on different company data types (e.g., financials, trading info, board details), but doesn't explicitly differentiate from 'get_company_governance_info' which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for governance regulations, it doesn't mention prerequisites (e.g., company must be listed), exclusions, or how it differs from similar tools like 'get_company_governance_info' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'obtains' information, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, or error handling. This leaves significant gaps for an agent to understand operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely defines return values), the description doesn't need to explain outputs. However, with no annotations, 0% schema description coverage, and many sibling tools, it lacks context on scope (e.g., what 'human development information' includes) and usage distinctions, making it minimally adequate but incomplete for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'based on its stock code,' which aligns with the single 'code' parameter in the schema. However, with 0% schema description coverage, it doesn't add details like format examples (e.g., ticker symbols), validation rules, or what constitutes a valid 'listed company.' The baseline is 3 since it minimally compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('human development information for a listed company'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like get_company_profile or get_company_governance_info, which might also provide related corporate information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools focused on company data (e.g., get_company_profile, get_company_governance_info), the description lacks context about what 'human development information' entails or when it's preferred over other company information tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'obtains' information, implying a read operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, error handling, or what 'inclusive finance information' entails (e.g., format, depth). This leaves significant gaps for an agent to understand how to invoke it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, resource, and key input, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and an output schema (which handles return values), the description is minimally adequate. However, it lacks context on what 'inclusive finance information' includes, potential errors, or usage scenarios, leaving gaps despite the output schema covering return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics: it implies the 'code' parameter is a stock code for a listed company. However, with 0% schema description coverage (the schema only lists 'code' as a string), the description doesn't compensate by detailing format (e.g., ticker symbol conventions), validation, or examples. The baseline is 3 due to the single parameter being straightforward, but it lacks enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and the resource 'inclusive finance information for a listed company', specifying it's based on a stock code. It distinguishes from many siblings that focus on different company data (e.g., financial reports, governance, trading info), but doesn't explicitly differentiate from 'get_companies_with_inclusive_finance_data', which might retrieve a list rather than details for a single company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., valid stock codes), exclusions, or compare it to sibling tools like 'get_companies_with_inclusive_finance_data' for broader queries. Usage is implied by the parameter but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool 'obtains' data, implying a read-only operation, but does not specify authentication needs, rate limits, data freshness, or error handling. For a tool accessing security data, this lack of detail is a significant gap, as it leaves the agent unaware of operational constraints, warranting a score of 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Obtain information security data for a listed company based on its stock code.' It is front-loaded with the core purpose and contains no redundant information, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving security data), no annotations, and an output schema present (which handles return values), the description is minimally adequate. It defines the purpose and parameter context but lacks behavioral details and usage guidelines. With the output schema covering return values, the description meets basic needs but has clear gaps, scoring a 3 as the minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It adds meaning by specifying that the 'code' parameter is a 'stock code' for a 'listed company', which clarifies the parameter's purpose beyond the schema's generic 'Code' title. However, it does not provide format details (e.g., ticker symbol conventions) or examples, resulting in a baseline score of 3 for adding some semantics but not fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtain information security data for a listed company based on its stock code.' It specifies the action ('obtain'), resource ('information security data'), and scope ('listed company'), but does not differentiate it from sibling tools like 'get_company_risk_management' or 'get_company_information_disclosure_violations', which might overlap in security-related data. This clarity earns a 4, as it's specific but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'based on its stock code' but does not specify prerequisites, exclusions, or compare it to sibling tools that might retrieve similar data (e.g., 'get_company_risk_management'). Without such context, an agent cannot make informed decisions, resulting in a score of 2 for minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool's function but omits critical details like whether it's read-only, requires authentication, has rate limits, or what the output format entails. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly while conveying the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple parameter, output schema exists), the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral context, usage guidelines, and detailed parameter semantics, which are needed for effective tool selection and invocation despite the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantic value beyond the input schema, which has 0% description coverage. It implies the 'code' parameter is a stock code for a listed company, but does not specify format, examples, or constraints. Given the low schema coverage, the description partially compensates but remains insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('monthly revenue information for a listed company'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_public_company_monthly_revenue', which might serve a similar function, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other revenue-related tools in the sibling list. It lacks context on prerequisites, exclusions, or specific scenarios, offering only a basic functional statement without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'obtain' which implies a read operation, but doesn't disclose behavioral traits like data freshness, rate limits, authentication needs, error conditions, or what 'ownership and control information' entails (e.g., structure, depth). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, resource, and key input constraint, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no annotations, but with an output schema), the description is minimally adequate. It explains what the tool does and the parameter's role, but lacks behavioral details and usage context. The output schema likely covers return values, so completeness is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that the parameter 'code' is a 'stock code', providing meaning beyond the schema's generic 'Code' title. However, with 0% schema description coverage and only one parameter, this minimal addition is sufficient for a baseline score, as the schema lacks details but the description clarifies the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('obtain') and resource ('ownership and control information for a listed company'), specifying it's based on a stock code. It distinguishes from many siblings that focus on different company data (e.g., financials, governance, trading), though not explicitly from similar tools like 'get_company_major_shareholders' or 'get_company_board_shareholdings'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description mentions 'based on its stock code' but doesn't specify prerequisites, exclusions, or compare with sibling tools that might overlap (e.g., 'get_company_major_shareholders'), leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'obtain' implies a read operation but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns structured data, handles errors, or provides real-time vs. historical info. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action ('obtain') and resource ('product lifecycle information'). It efficiently specifies the input requirement ('based on its stock code') without unnecessary details. Every word earns its place, making it highly concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is minimally adequate. It explains what the tool does but lacks behavioral context, usage guidelines, and parameter details. The presence of an output schema means return values are documented elsewhere, so the description doesn't need to cover outputs, but it should still address other gaps for better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic context. The description adds that the 'code' parameter is a 'stock code' for a 'listed company', which clarifies its purpose. However, it doesn't specify format (e.g., ticker symbol), validation rules, or examples, leaving some ambiguity. Given the low schema coverage, the description compensates partially but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and the resource 'product lifecycle information for a listed company', specifying it's based on 'stock code'. It distinguishes from siblings by focusing on product lifecycle data rather than financials, governance, or trading info. However, it doesn't explicitly contrast with specific sibling tools like get_company_profile or get_company_major_news, which might also provide company information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: use when you need product lifecycle info for a listed company using its stock code. It doesn't specify when NOT to use it, mention prerequisites (e.g., valid stock code format), or suggest alternatives among the many sibling tools (e.g., get_company_profile for general info). This leaves the agent with little context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'obtains' information, implying a read-only operation, but does not specify data sources, update frequency, authentication needs, rate limits, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, front-loading the key action and resource. It efficiently conveys the core purpose without unnecessary elaboration, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is adequate but incomplete. It covers the basic purpose and parameter intent but lacks behavioral details and usage guidelines, leaving room for improvement in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description adds minimal context by mentioning 'stock code' for the 'code' parameter. This provides basic meaning but lacks details like format, validation, or examples. Since schema coverage is low, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and the target resource ('product quality and safety information for a listed company'), making the purpose understandable. It does not explicitly differentiate from sibling tools (e.g., get_company_food_safety, get_company_risk_management), which focus on specific aspects, but the general scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, stating it's for 'a listed company based on its stock code', but offers no explicit when-to-use rules, alternatives, or exclusions compared to sibling tools like get_company_food_safety or get_company_risk_management. Usage context is implied but lacks specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation ('Obtain') but lacks details on permissions, rate limits, data freshness, or error handling. For a regulatory data tool, this omission is significant, though not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, clearly front-loading the purpose. It efficiently communicates the core function without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (regulatory data retrieval), no annotations, and an output schema present (which may cover return values), the description is minimally adequate. It states what the tool does but lacks details on behavioral traits, usage context, or parameter nuances, leaving gaps that could hinder effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by specifying 'stock code' as the input, but the schema has 0% description coverage and only one parameter ('code'). Since the description does not elaborate on format (e.g., ticker symbol, ISIN) or constraints, it provides basic context but does not fully compensate for the low schema coverage, aligning with the baseline for limited parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('SEC regulatory penalty information for a listed company'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_company_information_disclosure_violations' or 'get_company_anticompetitive_litigation', which might overlap in regulatory contexts, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other regulatory or company-specific tools in the sibling list. It mentions the input parameter ('stock code') but does not specify prerequisites, exclusions, or comparative contexts, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what information is obtained without mentioning whether this is a read-only operation, if it requires authentication, rate limits, data freshness, or error conditions. For a tool with no annotation coverage, this represents a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core purpose without unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), a single simple parameter, and no complex behavioral requirements, the description is minimally adequate. However, for a tool with zero annotation coverage and many similar siblings, it should provide more guidance on usage context and parameter specifics to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'based on its stock code' which maps to the single 'code' parameter, but with 0% schema description coverage, it doesn't specify format requirements (e.g., ticker symbol format), validation rules, or examples. The description adds basic context but doesn't fully compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and target resource ('supervisor compensation information for a listed company'), making the purpose understandable. However, it doesn't explicitly differentiate from similar sibling tools like 'get_company_consolidated_supervisor_compensation' or 'get_company_director_compensation', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by mentioning 'based on its stock code' but offers no explicit when-to-use instructions, no prerequisites, and no comparison to alternatives among the many sibling tools. This leaves the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but does not cover key aspects like whether it's a read-only operation, potential rate limits, authentication needs, or the format of the output. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations and minimal parameter details, it lacks completeness for a tool that likely involves data retrieval. It should provide more context on usage and behavior to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the parameter 'code' as a stock code, which adds semantic meaning beyond the schema's generic 'Code' title. However, with 0% schema description coverage and only one parameter, it partially compensates but does not fully detail constraints or examples, such as the expected format of the stock code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('supply chain management information for a listed company'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get_company_product_lifecycle' or 'get_company_risk_management', which might also relate to company operations, so it lacks sibling differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying the input ('based on its stock code'), but it does not indicate when to use this tool versus alternatives, such as other company-related tools in the sibling list. There is no mention of prerequisites, exclusions, or specific contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'obtains' information, implying a read-only operation, but doesn't disclose behavioral traits like data freshness, rate limits, authentication needs, error conditions, or what 'water resource management information' entails (e.g., metrics, reports). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core purpose ('Obtain water resource management information') and includes essential context ('for a listed company based on its stock code'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is minimally complete. It covers the basic purpose and parameter intent but lacks details on behavior, usage constraints, and parameter specifics, making it adequate but with clear gaps for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds that the parameter 'code' is a 'stock code' for a 'listed company', providing context beyond the schema's generic 'Code' title. However, it doesn't specify format (e.g., ticker symbol, ISIN), validation rules, or examples, leaving gaps for the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Obtain' and the resource 'water resource management information for a listed company', specifying it's based on a stock code. It distinguishes from many siblings that focus on other company aspects (e.g., financials, governance, trading), but doesn't explicitly differentiate from similar environmental tools like 'get_company_waste_management' or 'get_company_climate_management'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it implies usage when water management info is needed for a company with a known stock code. No explicit when-not-to-use scenarios, prerequisites (e.g., data availability), or alternatives (e.g., other environmental tools) are mentioned, leaving the agent to infer from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves data ('Get'), implying a read-only operation, but does not disclose behavioral traits like data freshness, rate limits, authentication needs, or output format. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core purpose, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple tool with 0 parameters, the description is minimal. It states what the tool does but lacks context on data scope, format, or behavioral aspects, making it incomplete for effective agent use despite low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add param details, which is appropriate, but it could have clarified if any implicit inputs (e.g., date) are required, though not strictly necessary given the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('daily available volume for securities lending'), specifying it relates to margin trading. However, it does not differentiate from siblings like 'get_margin_trading_info' or 'get_daily_market_trading_info', which might overlap in domain, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as sibling tools that might cover related data (e.g., 'get_margin_trading_info'). There is no mention of prerequisites, context, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read operation ('Get'), implying non-destructive behavior, but doesn't disclose any behavioral traits such as data freshness, rate limits, authentication needs, or output format. This is a significant gap for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of market data tools and lack of annotations or output schema, the description is incomplete. It doesn't explain what the holiday schedule includes (e.g., dates, markets), how it's formatted, or any limitations, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it also doesn't compensate for any gaps since there are none. A baseline of 4 is given as it adequately handles the zero-parameter case without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('holiday schedule for securities centralized trading market'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_twse_events' or 'get_today_notice_stocks' that might also provide market-related schedules, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for market data, the description lacks context about prerequisites, timing, or specific use cases, leaving the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical details: it doesn't specify if this is a read-only operation, what data format or time period the shareholdings cover, whether there are rate limits, or any authentication requirements. For a tool accessing financial data, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality without unnecessary words. It front-loads the key action ('Obtain board member shareholding details') and specifies the input requirement, making it easy to parse. Every part of the sentence earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (financial data retrieval), the description is incomplete: it lacks behavioral context, and while an output schema exists (which reduces the need to describe return values), the absence of annotations and low parameter coverage leaves gaps. The description covers the basic purpose but doesn't provide enough guidance for reliable use, especially with many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the parameter ('based on its stock code'), which aligns with the single 'code' parameter in the schema. However, with 0% schema description coverage, the schema provides no details about the parameter format (e.g., ticker symbol conventions, validation rules). The description adds minimal value by naming the parameter but doesn't compensate for the coverage gap with specifics like expected input format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and resource ('board member shareholding details for a public company'), making the purpose understandable. It specifies the input ('based on its stock code'), which helps distinguish it from tools that might use company names or other identifiers. However, it doesn't explicitly differentiate from similar sibling tools like 'get_company_board_shareholdings' or 'get_company_board_info', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by mentioning the input requirement ('based on its stock code'), but offers no context on when to use this tool versus alternatives. With many sibling tools related to company board information (e.g., 'get_company_board_info', 'get_company_board_shareholdings'), there's no indication of how this tool differs or when it's preferred, leaving the agent to guess based on naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions automatic industry detection and format adaptation, which adds some behavioral context, but doesn't disclose critical traits like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or error conditions. For a financial data tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, efficient sentences with zero waste. The first states the core purpose, the second adds valuable behavioral detail about industry detection. Well-structured and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and simple parameters, the description is minimally adequate. However, for a financial data retrieval tool with many sibling alternatives and no safety annotations, it should provide more context about data sources, update frequency, and usage boundaries to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 1 parameter, but the description clarifies that 'code' refers to 'stock code' for a public company. This adds meaningful semantics beyond the bare schema, though it doesn't specify format (e.g., ticker symbol conventions) or provide examples. With 0% coverage and only 1 parameter, the description does compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and resource 'comprehensive income statement for a public company', specifying it's based on stock code. It distinguishes from sibling 'get_company_income_statement' by specifying 'public company', though not explicitly contrasting with other financial tools like balance sheet or profitability analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_company_balance_sheet' or 'get_company_profitability_analysis'. The description mentions automatic industry detection and format adaptation, but doesn't provide context on prerequisites, limitations, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Obtain') but lacks details on data sources, update frequency, rate limits, authentication needs, or error handling. For a tool fetching financial data, this omission is significant, as it doesn't inform the agent about reliability or operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does and the required input, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial data retrieval), lack of annotations, and 0% schema description coverage, the description is minimally adequate. It states the purpose and parameter but misses behavioral context and detailed usage guidelines. The presence of an output schema helps by defining return values, but overall completeness is limited, scoring at the baseline for a simple tool with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It specifies that the parameter 'code' is a 'stock code', adding semantic meaning beyond the schema's generic 'Code' title. However, it doesn't clarify format (e.g., ticker symbol conventions), examples, or validation rules, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Obtain') and resource ('monthly revenue summary for a public company'), making the purpose specific and understandable. However, it does not explicitly differentiate from its sibling 'get_company_monthly_revenue', which might serve a similar purpose but potentially for different company types or data sources, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling 'get_company_monthly_revenue' or other financial data tools. It mentions the input ('stock code') but offers no context on prerequisites, limitations, or comparative use cases, leaving the agent without clear usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states it 'obtains' information without disclosing behavioral traits like data source, rate limits, or error handling. It implies a read operation but lacks details on permissions or response format, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, front-loading the key action and resource. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description need not explain return values, but with no annotations and low schema coverage, it should provide more context on behavior and usage. It is minimally adequate but lacks depth for a tool in a complex sibling environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by specifying that the 'code' parameter is a 'stock code' for a public company. This clarifies the parameter's purpose beyond the schema, though it does not detail format or constraints, meeting the baseline for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Obtain') and resource ('basic information for a public company'), making the purpose understandable. However, it does not differentiate from siblings like 'get_company_profile' or specify what 'basic information' entails, missing full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other company-related tools in the sibling list. The description lacks context on prerequisites or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Obtain historical data' implies a read-only operation, it doesn't specify what 'historical data' includes (time range, granularity, format), whether there are rate limits, authentication requirements, or what the response structure looks like. This leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded with the core functionality and wastes no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and many similar sibling tools, the description is insufficient. It doesn't explain what 'historical data' means in practice (time periods, data points included), how results are structured, or how this differs from other index history tools. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this. No additional parameter information is needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain historical data') and resource ('Taiwan Island Stock Price Index'), making the tool's purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_taiwan_50_index_history' or 'get_market_historical_index', which appear to serve similar historical index data functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to market indices and historical data (e.g., 'get_taiwan_50_index_history', 'get_market_historical_index'), there's no indication of what makes this specific Taiwan Island Index tool distinct or when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but does not specify aspects like data format, rate limits, authentication needs, or whether it returns real-time or historical information. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without redundancy or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's job is simplified. It states what the tool does but lacks details on output format or behavioral context, which could be inferred from the output schema. For a zero-param tool, this is minimally adequate but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could have mentioned any implicit context (e.g., date ranges if applicable). Given the zero-param baseline, a score of 4 reflects adequate handling without unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('after-hours fixed-price trading in the centralized market'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_block_trades_daily' or 'get_stock_daily_trading', which might also involve trading data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other trading-related tools in the sibling list. It lacks context on prerequisites, timing, or specific use cases, leaving the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool retrieves statistics, implying a read-only operation, but does not mention any constraints like rate limits, authentication needs, data freshness, or error handling. This leaves significant gaps in behavioral understanding for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without any unnecessary words. It is front-loaded and efficiently conveys the core purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists (which covers return values), and no annotations, the description is minimally adequate. However, it lacks context on data scope (e.g., date range defaults), sibling differentiation, and behavioral details, making it incomplete for optimal agent use despite the structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add parameter details, but since there are no parameters, this is acceptable. It implies the tool fetches daily data without specifying filters, which aligns with the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('daily block trade volume and value statistics'), making the purpose understandable. However, it does not explicitly differentiate from its siblings like 'get_block_trades_monthly' or 'get_block_trades_yearly', which offer similar statistics for different timeframes, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_block_trades_monthly' and 'get_block_trades_yearly', it lacks any indication of context, prerequisites, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but lacks details on data freshness, rate limits, authentication needs, or output format. This leaves significant behavioral gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core functionality without any wasted words. It is front-loaded with the essential action and resource, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has zero parameters, 100% schema coverage, and an output schema exists, the description's focus on purpose is adequate. However, without annotations and with sibling tools present, it lacks guidance on usage and behavioral context, making it minimally complete but with clear gaps in a rich server environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%, so there is no need for parameter explanation in the description. The description appropriately focuses on the tool's purpose without redundant parameter details, meeting the baseline for parameter-less tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('monthly block trade volume and value statistics'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'get_block_trades_daily' or 'get_block_trades_yearly', which would require specifying the time granularity distinction to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the daily or yearly versions listed among siblings. There is no mention of prerequisites, context, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but fails to mention any behavioral traits like rate limits, authentication needs, data freshness, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's job is minimal. However, for a tool with no annotations and many siblings, it lacks context on usage scenarios, data scope, or behavioral constraints. The description is adequate but leaves clear gaps in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could have clarified if any implicit parameters (e.g., year selection) are involved. Since there are no parameters, a baseline of 4 is applied, as the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('yearly block trade volume and value statistics'), making the purpose specific and understandable. However, it does not explicitly differentiate from its sibling tools like 'get_block_trades_daily' or 'get_block_trades_monthly', which would require mentioning temporal scope or data granularity to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the daily or monthly block trade tools listed among siblings. It lacks any context about prerequisites, frequency, or comparative use cases, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation ('Get') but does not specify whether it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core purpose, making it easy to scan and understand quickly. Every word contributes directly to clarifying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description adequately states what it does but lacks details on return format, error handling, or behavioral traits. With no annotations to supplement, it provides minimal context beyond the basic purpose, making it just sufficient but with clear informational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not need to add parameter details, and it appropriately avoids mentioning any. A baseline of 4 is applied since no parameters exist, and the description does not mislead about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'broker branch office basic information', making the purpose specific and understandable. It distinguishes from siblings like 'get_broker_basic_info' by specifying 'branch office' focus, though it could be more explicit about what 'basic information' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_broker_basic_info' or 'get_broker_headquarters_info'. The description lacks context about prerequisites, timing, or specific use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' implying a read operation, but doesn't disclose behavioral traits like data freshness, format of returned statistics, potential rate limits, or authentication needs. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate. However, with no annotations and many sibling tools, it lacks context on data scope (e.g., time range, broker selection) and output format, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 for not introducing unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get broker personnel gender statistics' clearly states the verb ('Get') and resource ('broker personnel gender statistics'), making the purpose immediately understandable. It distinguishes from siblings like 'get_broker_basic_info' or 'get_broker_service_personnel' by specifying gender statistics, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to brokers (e.g., 'get_broker_basic_info', 'get_broker_service_personnel'), the description lacks context on prerequisites, timing, or distinctions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get list') without detailing traits like read-only nature, potential rate limits, authentication needs, or output format. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks details on behavioral traits and usage context, which are important for completeness even in simple cases, making it just sufficient but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add param info, which is acceptable here, but it also doesn't provide any context about filtering or scoping, slightly limiting utility. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get list') and resource ('brokers offering regular investment services'), making the purpose explicit. However, it does not distinguish this tool from its many siblings (e.g., get_broker_basic_info, get_broker_service_personnel), which also retrieve broker-related data, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With numerous sibling tools focused on brokers and companies, there is no indication of context, prerequisites, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('Get companies'), implying it's non-destructive, but doesn't specify any behavioral traits such as data freshness, rate limits, authentication requirements, or potential side effects. For a tool with zero annotation coverage, this lack of additional context is a significant gap, leaving the agent uncertain about operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action ('Get companies') and specifies the criteria concisely. Every word earns its place by defining the scope without redundancy or fluff, making it highly efficient and easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with 0 parameters), schema coverage is 100%, and an output schema exists, the description is minimally adequate. It states what the tool does but lacks context on behavioral aspects, usage guidelines, or output interpretation. With no annotations and reliance on the output schema for return values, the description meets basic needs but leaves gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, meaning the input schema fully documents the absence of parameters. The description doesn't need to add parameter semantics, as there are none to explain. A baseline score of 4 is appropriate because the description efficiently states the tool's purpose without unnecessary parameter details, aligning with the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get companies') and specifies the criteria ('that use cumulative voting, full roll-call voting, or nominee nomination systems for electing directors and supervisors'). It distinguishes itself from sibling tools by focusing on specific corporate governance voting systems, unlike other tools that cover different aspects like financial data, trading info, or other governance features. However, it doesn't explicitly contrast with the most similar sibling 'get_companies_with_independent_directors', which is also governance-related but targets a different criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for application, or compare with sibling tools that might overlap in governance queries (e.g., 'get_companies_with_independent_directors'). The agent must infer usage based solely on the purpose statement, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the query criteria but doesn't mention any behavioral traits such as read-only vs. destructive nature, authentication requirements, rate limits, pagination, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads all necessary information: 'Get companies with ownership changes that also have major business scope changes and were suspended from trading.' It is appropriately sized with zero wasted words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (querying companies with multiple criteria), no annotations, and an output schema (which handles return values), the description is minimally adequate. It specifies the criteria but lacks behavioral context (e.g., safety, performance). With output schema covering returns, it meets basic needs but could be more complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description doesn't add parameter details, which is appropriate. A baseline of 4 is applied because the schema fully documents the absence of parameters, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get companies with ownership changes that also have major business scope changes and were suspended from trading.' It specifies the verb ('Get') and the resource ('companies') with three specific criteria, making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_companies_with_ownership_changes' or 'get_companies_with_business_scope_changes', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists the criteria but doesn't mention prerequisites, exclusions, or compare it to similar sibling tools (e.g., 'get_companies_with_ownership_changes' or 'get_companies_with_business_scope_changes'). This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't specify any behavioral traits such as rate limits, authentication needs, data freshness, or pagination. The description is minimal and lacks context about how the data is retrieved or any operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. There's no wasted text, and it effectively communicates the essential information in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a tool with no parameters and an output schema (which handles return values). However, given the complexity implied by the tool name (involving ownership changes, business scope changes, and trading method transitions) and the lack of annotations, the description could benefit from more context about data sources, limitations, or typical use cases to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate since none exist. This aligns with the baseline expectation for a tool with no parameters, as there's nothing to compensate for, and the description doesn't need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'companies with ownership changes and major business scope changes that were changed to trading method.' It specifies the type of companies retrieved (those with ownership and business scope changes that transitioned to trading method), which distinguishes it from general company retrieval tools. However, it doesn't explicitly differentiate from similar siblings like 'get_companies_ownership_changes_business_scope' or 'get_companies_with_business_scope_changes', which might overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for usage. Given the many sibling tools (e.g., 'get_companies_ownership_changes_business_scope'), there's no indication of how this tool differs in application, leaving the agent to infer based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this is a read-only operation, what the output format is, potential rate limits, or error conditions. The presence of an output schema helps, but the description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, 100% schema coverage, and an output schema, the description covers the basic purpose adequately. However, for a tool with no annotations and complex context (CSR reports, 103 year), it lacks explanation of terms, output structure hints, or error handling, making it minimally complete but with gaps in user guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is given as it avoids unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'companies required to prepare and submit CSR reports in 2014 (103 year)', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_companies_with_inclusive_finance_data' or 'get_companies_with_anticompetitive_losses', which also filter companies based on different criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for 'CSR reports' or '103 year', or compare it to other company-filtering tools in the sibling list, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but does not specify details like data freshness, rate limits, authentication needs, or what 'information about independent directors' entails. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficient, with no wasted information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the basic purpose adequately. However, with no annotations and a broad scope ('information about independent directors'), it lacks details on output format, data constraints, or behavioral traits, leaving room for improvement in completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 parameters, 100% schema description coverage), so the description does not need to add parameter details. It appropriately focuses on the tool's purpose without redundant parameter explanations, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all listed companies with information about independent directors'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_company_board_info' or 'get_company_governance_info', which might also relate to company governance or board data, leaving some ambiguity in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other company-related tools in the sibling list. It lacks context on prerequisites, exclusions, or specific scenarios, offering only a basic statement of function without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions filtering criteria ('excluding zero or N/A values') but does not disclose behavioral traits like data source, update frequency, rate limits, authentication needs, or potential side effects. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any redundant or verbose language. It is front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and a lack of behavioral context (e.g., data freshness, error handling), it falls short of being fully complete for informed agent use, though the output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add parameter semantics, which is appropriate here, and the baseline score for 0 parameters is 4, as it avoids unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all listed companies') and the specific criteria ('that have reported refineries in populated areas, excluding zero or N/A values'), making the purpose explicit. However, it does not explicitly differentiate from sibling tools, which all start with 'get_' and target various company attributes, though the specificity of 'refineries in populated areas' inherently distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as which sibling tools might overlap or serve similar purposes. It lacks any mention of prerequisites, exclusions, or contextual triggers for invocation, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the automatic industry detection and format adaptation behavior, which is useful context beyond basic functionality. However, it doesn't mention critical behavioral traits like whether this is a read-only operation, data freshness, rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a bulleted list of industry-specific formats. There's no wasted text, though the bulleted list could be slightly condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and an output schema (which handles return values), the description provides adequate context. It covers the tool's purpose, parameter meaning, and key behavioral aspect (industry detection). However, it lacks usage guidelines and full behavioral transparency, which are gaps for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that the 'code' parameter is a 'stock code' for a 'listed company', adding meaningful context beyond the schema's generic 'Code' title. However, it doesn't provide format examples, validation rules, or details about the industry detection logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Obtain') and resource ('balance sheet for a listed company'), specifying it's based on stock code. It distinguishes from siblings like 'get_company_income_statement' by focusing on balance sheets, but doesn't explicitly differentiate from 'get_public_company_balance_sheet' (a sibling tool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions automatic industry detection and format adaptation, but doesn't specify prerequisites, limitations, or compare to sibling tools like 'get_public_company_balance_sheet' (which might serve a similar purpose).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't clarify aspects like data freshness, rate limits, authentication requirements, or what 'insufficient shares as required by law' entails legally. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the main action and criteria, making it easy to parse quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description doesn't need to cover parameters or return values. However, it lacks context on legal definitions, data scope, or behavioral traits, which could be important for accurate use. The description is minimally adequate but leaves room for improvement in clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline score of 4 is given as the description doesn't need to compensate for any parameter gaps, but it doesn't provide extra semantic context either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all listed companies') and the specific criteria ('where board members hold insufficient shares as required by law'), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling 'get_company_board_insufficient_shares_consecutive', which appears related but with potentially different criteria (e.g., consecutive occurrences).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for 'insufficient shares as required by law', or how it differs from similar tools like 'get_company_board_shareholdings' or 'get_company_board_insufficient_shares_consecutive', leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get') but does not specify data freshness, rate limits, permissions needed, or output format details. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0 parameters, 100% schema coverage, and an output schema, the description is minimally adequate. However, it lacks details on behavioral aspects like data sources or constraints, which are important given the complexity implied by 'consecutive months'. The output schema helps, but more context could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could have mentioned implicit filters or defaults. Given the lack of parameters, a baseline of 4 is applied as it adequately handles the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target resource ('companies where board members have held insufficient shares for 3 consecutive months or more'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_company_board_insufficient_shares' (which lacks the 'consecutive' aspect), missing full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling 'get_company_board_insufficient_shares' or other board-related tools. It lacks context on prerequisites, exclusions, or specific scenarios for application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states what data is retrieved, it doesn't mention any behavioral traits such as data freshness, rate limits, authentication requirements, or whether this is a read-only operation (implied by 'Get' but not explicit). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without any wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has zero parameters, 100% schema coverage, and an output schema exists, the description's job is simplified. It adequately explains what data is retrieved, but with no annotations and many sibling tools, it could benefit from more context about data scope or limitations. The existence of an output schema means return values don't need explanation, keeping the description minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied since no parameter information is needed, and the description doesn't attempt to add unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('board members' pledged shares as a percentage of their actual holdings'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_company_board_shareholdings' or 'get_company_board_insufficient_shares', which likely provide related but different data about board member holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools focused on company board data (e.g., 'get_company_board_shareholdings', 'get_company_board_insufficient_shares'), there's no indication of what distinguishes this tool's specific focus on pledged shares percentage from other board-related metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information (a read operation), but doesn't specify data sources, accuracy, update frequency, or output format. While the presence of an output schema helps, the description lacks context on limitations or reliability, which is a gap for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an AI agent to parse quickly. This is an example of optimal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema provided), the description is minimally adequate. It states what the tool does, but lacks behavioral context (e.g., data freshness, scope limitations) that would be helpful despite the output schema. For a read-only tool with no annotations, more detail on reliability or constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the input requirements. The description doesn't need to add parameter details, and it doesn't introduce any confusion. A baseline of 4 is appropriate as the description doesn't compensate for missing param info (none needed) but also doesn't add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get information about whether company chairmen also serve as CEOs.' It specifies the verb ('Get information') and resource ('company chairmen'), and distinguishes it from siblings by focusing on dual CEO/chairman roles. However, it doesn't explicitly differentiate from similar governance tools like 'get_company_board_info' or 'get_company_governance_info', which might overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, nor does it reference any of the many sibling tools that might provide related governance or company information. Usage is implied only by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'obtains' information, implying a read operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, what format the output is in (though output schema exists), or if it handles invalid codes. The description is minimal and lacks context on how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and resource. There's no wasted verbiage, repetition, or unnecessary details, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with low schema coverage (0%) but an output schema exists, the description is minimally complete. It covers the basic purpose and parameter semantics but lacks usage guidelines and behavioral transparency, which are gaps for a tool with no annotations. The output schema mitigates the need to explain return values, but overall context is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'code' parameter is a 'stock code' for a 'listed company', which clarifies its purpose beyond the schema's generic 'Code' title and string type. With 0% schema description coverage and only 1 parameter, this compensation is adequate, though it doesn't detail format constraints (e.g., ticker symbols).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and the resource 'community relations information for a listed company', specifying it's based on the stock code. It distinguishes from many siblings that focus on different company data (e.g., financials, governance, trading), but doesn't explicitly differentiate from all possible overlaps like CSR reports or inclusive finance data, which are related but not identical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., valid stock codes), exclusions, or compare to siblings like 'get_companies_with_csr_reports_103' or 'get_company_inclusive_finance', which might overlap in community-related data. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'obtain' which implies a read operation, but doesn't disclose behavioral traits like whether it's real-time or historical data, format of returns, rate limits, authentication needs, or error handling. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word contributes to understanding what the tool does, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage, an output schema exists (which helps), and no annotations, the description is minimally adequate. It covers the basic purpose and parameter context but lacks details on usage, behavior, or output specifics, leaving room for improvement in guiding an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'code' parameter should be a 'stock code' for a 'listed company', which clarifies its purpose beyond the schema's generic 'Code' title. With 0% schema description coverage and only 1 parameter, this provides adequate compensation, though it doesn't detail format (e.g., ticker symbol conventions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtain' and the resource 'investor communications information for a listed company', specifying it's based on stock code. However, it doesn't differentiate from sibling tools like get_company_shareholder_meeting_announcements or get_company_major_news, which might also relate to investor communications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools focused on company information (e.g., get_company_profile, get_company_major_news), the description lacks context on what specific type of investor communications it retrieves or when it's preferred over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output format ('JSON string object'), which is helpful, but lacks critical behavioral details: it doesn't specify what 'basic information' includes, whether there are rate limits or authentication requirements, if the data is real-time or historical, or error handling for invalid codes. For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word contributes: 'Obtain' (action), 'basic information' (scope), 'listed company' (resource), 'JSON string object' (output format), and 'stock code' (input). There's no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely defines the JSON structure), the description doesn't need to detail return values. However, with no annotations and 0% schema description coverage, it should do more to explain behavioral aspects like data freshness or error cases. The description is adequate as a minimal overview but lacks depth for a tool that might involve external data fetching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter by specifying it's a 'stock code', which clarifies the input beyond the schema's generic 'Code' title. With 0% schema description coverage, this compensates well. However, it doesn't provide examples or format details (e.g., ticker symbol conventions), leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain'), resource ('basic information of a listed company'), and output format ('as a JSON string object'). It specifies the input parameter ('based on its stock code'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_public_company_profile' or other company-specific tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools focused on specific company data aspects (e.g., 'get_company_balance_sheet', 'get_company_major_shareholders'), there's no indication that this tool provides 'basic information' as opposed to more detailed or specialized data. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read operation ('obtain') but lacks details on permissions, rate limits, data freshness, or output format. While it hints at variance calculation, behavioral traits like error handling or response structure are omitted, making it insufficient for a tool with output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that efficiently conveys the tool's purpose, resource, filtering logic, and parameter use without redundancy. It is front-loaded with the core action and appropriately sized, with every word contributing to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description needn't explain return values. However, with no annotations and a single parameter, it adequately covers the basic purpose and parameter semantics but lacks behavioral context and usage guidelines, leaving gaps in overall completeness for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter 'code', the description adds crucial meaning by specifying it as a 'stock code' for a 'listed company', clarifying its purpose beyond the generic schema. This compensates well for the lack of schema documentation, though it doesn't detail format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('obtain quarterly comprehensive income audited/reviewed figures') and resource ('for a listed company'), specifying the filtering condition ('differ from forecast by more than 10%') and identifier ('based on its stock code'). It distinguishes from siblings by focusing on audit variance rather than other financial or governance data, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for variance analysis but doesn't mention prerequisites, exclusions, or compare with other tools like get_company_quarterly_earnings_forecast_achievement, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'obtain' which suggests a read operation, but doesn't disclose behavioral traits such as data freshness, rate limits, authentication needs, error handling, or what the output contains. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose without unnecessary words. Every part earns its place by specifying the action, resource, and key parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and low complexity with 1 parameter, the description is minimally adequate. However, with no annotations and incomplete behavioral disclosure, it lacks completeness for safe and effective use, such as missing error cases or data scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'code' parameter is a 'stock code' for a 'listed company', which clarifies beyond the schema's generic 'Code' title and string type. With 0% schema description coverage and 1 parameter, this adequately compensates, though it doesn't detail format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('obtain') and target ('risk management policy information for a listed company'), specifying it's based on stock code. It distinguishes from siblings by focusing on risk management policies rather than financials, governance, or other company data, though it doesn't explicitly contrast with specific alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_company_governance_info or get_company_profile, which might overlap in scope. The description implies usage for risk management data but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'comprehensive' announcements 'with all available information', which implies a read-only, non-destructive operation, but lacks details on output format, pagination, rate limits, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get comprehensive shareholder meeting announcements') and adds a clarifying temporal scope. There is no wasted verbiage, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is adequate but minimal. It lacks details on behavioral traits (e.g., data freshness, limitations) and does not differentiate from sibling tools, which could lead to confusion. For a tool with no parameters, more context on usage and output expectations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by implying a temporal filter ('since 2008'), which may be a default or implicit parameter, but does not clarify if this is adjustable or fixed. This slight ambiguity prevents a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('comprehensive shareholder meeting announcements') with a temporal scope ('since 2008'), making the purpose specific and understandable. However, it does not explicitly differentiate from its sibling tool 'get_company_shareholder_meeting_announcements_by_code', which likely filters by company code, leaving some ambiguity about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling tool 'get_company_shareholder_meeting_announcements_by_code'. It mentions a temporal scope ('since 2008') but does not specify if this is a default, required, or optional filter, nor does it indicate any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't specify any behavioral traits such as authentication requirements, rate limits, data freshness, or error handling. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information without any wasted words. It directly states the tool's purpose, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, without annotations and with many sibling tools, it lacks context on usage and behavioral aspects, making it incomplete for optimal agent guidance. The output schema may cover return values, but the description doesn't address when or why to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate since none exist. This aligns with the schema, so it earns a baseline score of 4 for not introducing confusion, though it doesn't add extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resources ('shareholder meeting dates, locations and electronic voting information'), making the purpose unambiguous. However, it doesn't differentiate this tool from sibling tools like 'get_company_shareholder_meeting_announcements' or 'get_company_shareholder_meeting_announcements_by_code', which appear related but are not explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available, including those with similar names like 'get_company_shareholder_meeting_announcements', there is no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves information, implying a read-only operation, but does not disclose behavioral traits such as data freshness, rate limits, authentication needs, or output format. This is a significant gap for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for its simple function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks behavioral context (e.g., data scope, limitations) that would be helpful for an agent, especially with no annotations. It meets basic needs but has clear gaps in transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. Baseline is 4 for zero parameters, as it avoids unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('daily cross-market trading information for listed and OTC stocks'), providing a specific purpose. However, it does not explicitly differentiate from sibling tools like 'get_daily_market_trading_info' or 'get_stock_daily_trading', which might cover similar data, so it lacks full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent without usage instructions. Sibling tools suggest potential overlaps, but no explicit alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a 'Get' operation, implying read-only access, but doesn't mention any behavioral traits such as data freshness, rate limits, authentication needs, or what 'first-listed' specifically means. This leaves significant gaps for a tool that likely accesses financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without any wasted words. It's front-loaded with the key action and resource, making it easy to parse quickly, which is ideal for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks context about data scope (e.g., time range, market), behavioral details, and differentiation from siblings, which could be important for accurate tool selection in a complex server with many related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have mentioned if any implicit parameters (like date defaults) exist. Since there are no parameters, a baseline of 4 is applied, as the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('daily trading volume and value of first-listed foreign stocks'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_foreign_investment_by_industry' or 'get_top_foreign_holdings', which might also involve foreign stocks, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to foreign stocks, market data, and daily trading, there's no indication of context, prerequisites, or exclusions that would help an agent choose appropriately among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('Get...') without any information on permissions, rate limits, response format, or potential side effects. This is inadequate for a tool with zero annotation coverage, as it leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or unnecessary details. It is appropriately sized and front-loaded, making it easy to parse and understand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists (which handles return values), the description's job is simplified. It adequately states the purpose but lacks behavioral context (e.g., data freshness, access constraints) that would be helpful despite the output schema. It's minimally viable but has clear gaps in completeness for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation for a parameterless tool, earning a high score for not introducing confusion or redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('foreign companies applying for first listing on TWSE'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from its sibling 'get_local_companies_applying_for_listing' beyond the 'foreign' vs 'local' distinction in the name, which is why it doesn't achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or contextual cues for selection among the many sibling tools, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get basic information summary' but does not specify if this is a read-only operation, whether it requires authentication, rate limits, or what the output format might be. This leaves significant gaps for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no output schema, and no annotations, the description is minimally adequate but lacks depth. It states what the tool does but does not cover behavioral aspects like safety, output format, or usage context, which are important for a tool with no structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter details are needed. The description does not add parameter semantics, but with no parameters, a baseline of 4 is appropriate as there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('basic information summary for all funds'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools, as none appear to be fund-specific alternatives, but the scope 'all funds' is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It simply states what it does without context, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it is non-destructive, but does not address potential limitations like rate limits, authentication needs, data freshness, or return format details. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's purpose, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks behavioral context (e.g., data scope, update frequency) and does not differentiate from siblings, leaving room for improvement in guiding effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description does not add or detract from parameter semantics, but the absence of parameters justifies a high baseline score as there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('local companies applying for listing'), making the purpose understandable. However, it does not differentiate from sibling tools like 'get_foreign_companies_applying_for_listing' beyond the 'local' qualifier, which is implied but not explicitly contrasted, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_foreign_companies_applying_for_listing' or 'get_recently_listed_companies'. It lacks context about prerequisites, timing, or specific use cases, offering only a basic statement of purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' an announcement, implying a read-only operation, but doesn't disclose behavioral aspects like whether this requires authentication, rate limits, freshness of data, or what format the announcement returns. For a financial data tool with zero annotation coverage, this leaves critical gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It's appropriately sized for a zero-parameter tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, 100% schema coverage, and an output schema exists, the description covers the basic purpose adequately. However, with no annotations and a complex sibling set, it lacks guidance on usage context and behavioral traits, making it minimally viable but incomplete for optimal agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so the description doesn't need to explain any inputs. It appropriately focuses on the output (announcement retrieval) without redundant parameter details. A baseline of 4 is justified since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get announcement') and the specific resource ('margin loan and short sale restrictions'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its many siblings (e.g., get_suspended_day_trading_announcement, get_shareholder_meeting_announcements) that also retrieve announcements, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 100+ sibling tools, there's no indication of context, prerequisites, or exclusions. The agent must infer usage from the name alone, which is insufficient for a complex financial domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtains' information, implying a read-only operation, but doesn't specify data freshness (e.g., real-time vs. delayed), rate limits, authentication requirements, or error conditions. For a financial data tool with zero annotation coverage, this is insufficient to guide safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('obtain margin trading and short selling balance information') and the scope ('for the market'), with zero wasted text. This is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains the purpose but lacks behavioral context (e.g., data latency, error handling) and usage guidelines relative to siblings. For a market data tool in a crowded sibling set, more guidance would improve completeness, but it meets the baseline for a no-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are required or documented. The description doesn't add parameter details, which is appropriate since there are none to explain. A baseline score of 4 is given for tools with zero parameters, as there's no need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtain margin trading and short selling balance information for the market.' It specifies the verb ('obtain') and the resource ('margin trading and short selling balance information'), and the scope ('for the market') distinguishes it from company-specific tools in the sibling list. However, it doesn't explicitly differentiate from other market-level tools like 'get_daily_market_trading_info' or 'get_cross_market_trading_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools focused on market data (e.g., 'get_daily_market_trading_info', 'get_cross_market_trading_info'), there's no indication of whether this tool is for real-time data, historical data, or specific market segments. It lacks any 'when-to-use' or 'when-not-to-use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states 'Get stocks that have been disposed by the market,' which implies a read operation but doesn't specify details like data format, pagination, rate limits, or authentication needs. For a tool with zero annotation coverage, this is insufficient, as it leaves key behavioral aspects undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get stocks that have been disposed by the market.' It's front-loaded with the core action and resource, with no wasted words or redundant information, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's job is reduced. However, it lacks details on behavioral aspects like data scope or format, which could be important for an AI agent. It's minimally adequate but leaves gaps in understanding how the tool behaves in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any unnecessary complexity. A baseline score of 4 is appropriate since no parameters exist, and the schema fully covers this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get stocks that have been disposed by the market' clearly states the verb ('Get') and resource ('stocks that have been disposed by the market'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_suspended_trading_stocks' or 'get_suspended_listed_companies', which might relate to similar market actions, so it lacks specific sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and with many sibling tools available (e.g., 'get_suspended_trading_stocks'), there's no indication of how this differs or when it's appropriate, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtains' data, implying a read-only operation, but does not clarify aspects like data freshness, rate limits, authentication needs, or potential errors. For a tool with zero annotation coverage, this lack of behavioral context is a significant gap, though it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and intended use. It is front-loaded with the core action ('Obtain historical TAIEX data') and adds value with the context ('for long-term trend analysis'). There is no wasted wording, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description provides a basic but incomplete picture. It covers the purpose and use case but lacks details on behavioral traits (e.g., data format, limitations) that would be needed for full contextual understanding. For a simple tool, this is minimally adequate but leaves gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not mention any parameters, which is appropriate here. Since there are no parameters to explain, the description adequately sets expectations without redundancy, earning a baseline score of 4 for not introducing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtain historical TAIEX data for long-term trend analysis.' It specifies the verb ('obtain'), resource ('historical TAIEX data'), and intended use ('long-term trend analysis'). However, it does not explicitly differentiate from sibling tools like 'get_taiwan_50_index_history' or 'get_taiwan_island_index_history', which might also provide historical index data, leaving some ambiguity about uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions 'long-term trend analysis,' which implies a context for use, but does not specify when to choose this tool over alternatives (e.g., vs. other historical index tools in the sibling list) or any prerequisites. No explicit when-not-to-use or alternative recommendations are included, limiting its utility for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'historical query' but doesn't specify time ranges, data formats, pagination, rate limits, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core purpose ('Get historical query') and specifies the exact resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks context on data scope (e.g., time period, completeness) and behavioral traits, which could be important for a historical query tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have mentioned if any implicit parameters (like date ranges) are handled internally. A baseline of 4 is given since the schema fully covers the parameter aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('historical query of suspended buy-sell-same-day trading'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling 'get_suspended_day_trading_announcement', which appears related but might serve a different function (announcements vs. historical data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'get_suspended_day_trading_announcement', 'get_daily_day_trading_targets'), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read operation ('Get'), implying it's likely non-destructive, but does not disclose any behavioral traits such as rate limits, authentication needs, response format, or whether it returns real-time or historical data. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, without annotations and with many sibling tools, it lacks context on differentiation, behavioral details, or output expectations, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add any parameter details, which is appropriate, but it could have mentioned if there are implicit filters (e.g., by date or market). Since parameters are not required, a baseline of 4 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get companies whose listing has been suspended' clearly states the verb ('Get') and resource ('companies whose listing has been suspended'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_suspended_trading_stocks' or 'get_suspended_day_trading_announcement', which might have overlapping or related scopes, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to suspensions (e.g., 'get_suspended_trading_stocks'), there is no indication of context, exclusions, or prerequisites, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but lacks behavioral details such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format entails. The description is minimal and does not compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and appropriately sized for a no-parameter tool, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and no annotations, the description is minimally adequate. However, it lacks context about the output (e.g., what data is returned, format) and behavioral traits, which could be helpful despite the output schema. It meets basic requirements but leaves gaps in full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate here. A baseline of 4 is applied since the schema fully covers the parameters (none), and the description doesn't introduce confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('stocks suspended from trading in the centralized market'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_suspended_day_trading_announcement' or 'get_suspended_day_trading_history', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to suspensions (e.g., 'get_suspended_day_trading_announcement'), there is no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does without mentioning any behavioral traits like data freshness, format, time range, rate limits, or authentication needs. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized for a zero-parameter tool, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's zero parameters and lack of annotations or output schema, the description is minimally adequate but incomplete. It does not cover behavioral aspects like data format, time range, or limitations, which are important for a historical data tool, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%, so no parameter information is needed. The description does not add parameter details, which is appropriate, but it also doesn't clarify any implicit parameters (e.g., date ranges), slightly reducing the score from a perfect 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Obtain') and resource ('historical data for Taiwan 50 Index'), making the purpose specific and understandable. However, it does not distinguish this tool from its sibling 'get_taiwan_island_index_history' or other index-related tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_taiwan_island_index_history' or other market index tools. There are no explicit instructions on context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtains' data, implying a read-only operation, but lacks details on data freshness, rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core purpose ('Obtain Taiwan Capitalization Weighted Stock Price Return Index') without unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, no output schema), the description is minimally adequate. It states what data is retrieved but lacks context on data format, time range, or how it differs from similar indices. For a tool in a server with many market data siblings, more differentiation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description does not need to explain parameters, and it appropriately avoids mentioning any. A baseline of 4 is applied since no parameters exist, and the description does not introduce confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and the specific resource ('Taiwan Capitalization Weighted Stock Price Return Index'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_taiwan_50_index_history' or 'get_taiwan_island_index_history', which also retrieve Taiwan market indices, leaving some ambiguity about scope or data type distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to Taiwan market data (e.g., 'get_taiwan_50_index_history', 'get_market_historical_index'), there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns historical or real-time data, or handles errors. For a tool with zero annotation coverage, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('Get stock P/E ratio, dividend yield and P/B ratio') and adds the key constraint ('by date query'), making it easy to parse quickly. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters (schema coverage 100%) and no output schema, the description is minimally adequate. It explains the purpose and hints at date-based querying, but lacks details on behavioral traits (e.g., data freshness, error handling) and doesn't clarify output format or structure. For a simple retrieval tool, it meets basic needs but leaves gaps in full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema already fully documents that no inputs are required. The description adds value by implying a 'date query' is involved, suggesting the tool might use contextual or default dates, but it doesn't specify how dates are handled (e.g., format, default to today). This extra semantic hint compensates slightly, earning a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get stock P/E ratio, dividend yield and P/B ratio by date query.' It specifies the verb ('Get'), resource ('stock P/E ratio, dividend yield and P/B ratio'), and scope ('by date query'). However, it doesn't explicitly differentiate from sibling tools like 'get_stock_valuation_ratios' (which appears to be similar but without the date query specification), so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'by date query' but doesn't clarify if this is for a specific date, date range, or how it compares to other valuation tools in the sibling list (e.g., 'get_stock_valuation_ratios'). There's no mention of prerequisites, exclusions, or recommended contexts, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions filtering out 'zero or N/A values', which adds some behavioral context, but does not disclose other traits like data freshness, pagination, rate limits, or authentication needs. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the purpose. It is appropriately sized for a tool with no parameters and good output schema support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and no annotations, the description is reasonably complete for its purpose. It specifies the filtering logic ('excluding zero or N/A values'), but could improve by mentioning output format or data scope limitations. The output schema reduces the need for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could have mentioned implicit filters like date ranges if applicable. Baseline is 4 due to zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all listed companies that have reported inclusive finance activities', specifying the scope with 'excluding zero or N/A values'. It distinguishes from siblings like 'get_company_inclusive_finance' by focusing on aggregated company-level data rather than detailed reports, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_company_inclusive_finance' for detailed data or other company-filtering tools. The description implies usage for retrieving companies with non-zero inclusive finance data but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by using 'Get' and details the output format, which adds value. However, it does not disclose behavioral traits like rate limits, authentication needs, or data freshness, leaving gaps for a tool that likely involves market data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the purpose, followed by a clear list of returned statistics. It is efficient with minimal waste, though the list of statistics is somewhat lengthy but necessary for clarity. Every sentence serves a purpose, making it concise and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (market statistics retrieval) and lack of annotations and output schema, the description is adequate but incomplete. It explains the output format in detail, which helps, but does not cover behavioral aspects like data sources, update frequency, or error handling. For a tool with no structured support, it meets minimum viability but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate. It adds value by detailing the output structure, compensating for the lack of an output schema, but since parameters are absent, a baseline of 4 is applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get market statistics of rising and falling securities.' It specifies the verb ('Get') and resource ('market statistics'), making it easy to understand. However, it does not explicitly differentiate from sibling tools, such as 'get_daily_market_trading_info' or 'get_real_time_trading_stats', which might overlap in scope, so it lacks sibling distinction for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists the returned statistics but does not mention context, prerequisites, or exclusions. With many sibling tools available (e.g., 'get_daily_market_trading_info'), the absence of usage guidelines leaves the agent uncertain about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions filtering criteria ('excluding zero or N/A values'), it lacks details on data sources, update frequency, potential limitations (e.g., date ranges, completeness), or what the output schema contains. For a tool with no annotations, this leaves significant gaps in understanding its behavior and reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key filtering rule ('excluding zero or N/A values'). It is front-loaded with the main action and avoids any redundant or verbose language, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, 100% schema coverage, and an output schema exists, the description doesn't need to cover parameters or return values. However, with no annotations and a potentially complex data source (anti-competitive litigation losses), the description could benefit from more context on data scope or limitations to fully inform usage, leaving it adequate but with room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the tool's function without unnecessary parameter details, earning a baseline score of 4 for effectively handling a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target ('all listed companies that have reported monetary losses from anti-competitive litigation'), making the purpose explicit. However, it doesn't distinguish this tool from its sibling 'get_company_anticompetitive_litigation', which appears to be a related but different tool for company-specific data rather than aggregated company lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by specifying 'excluding zero or N/A values,' which indicates when data points are filtered out. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_company_anticompetitive_litigation' or other company-filtering tools, leaving the choice somewhat 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool's function but lacks critical details such as whether it's a read-only operation, any rate limits, authentication requirements, or what the output format entails. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key parameter context without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema, the description is adequate but incomplete. It covers the basic purpose and parameter meaning but lacks behavioral details like safety or performance traits, which are important since no annotations are provided. The output schema mitigates some gaps, but overall completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter by specifying that 'code' refers to a 'stock code' for a 'listed company,' which clarifies its semantics beyond the schema's minimal title. Since there are 0 parameters with schema description coverage, this compensation is effective, though it doesn't detail format constraints like length or allowed characters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Obtain') and target resource ('director compensation information for a listed company'), making the purpose specific and understandable. It distinguishes from siblings by focusing on director compensation rather than other company data like financial reports or governance info, though it doesn't explicitly contrast with similar tools like get_company_consolidated_director_compensation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'for a listed company based on its stock code,' which suggests when to use it. However, it provides no explicit guidance on when to choose this tool over alternatives like get_company_consolidated_director_compensation or when not to use it, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format and data fields well, but fails to mention critical operational aspects such as whether this is a read-only operation, any rate limits, authentication requirements, data freshness guarantees, or potential errors. For a real-time data tool, these omissions are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a bulleted list of return fields. Every sentence adds value, though the second sentence could be slightly more concise by integrating the bullet list introduction more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (real-time data retrieval with detailed metrics), no annotations, and no output schema, the description does a reasonable job explaining what data is returned. However, it lacks important context about operational behavior, data sources, update frequency, and error conditions that would be needed for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics instead, detailing the structure and meaning of returned statistics. This exceeds the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('obtain', 'returns') and resources ('real-time 5-second trading statistics'), including detailed metrics like order volumes and transaction counts. It effectively distinguishes itself from sibling tools by focusing on high-frequency interval data rather than daily, monthly, or company-specific information found in other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While the focus on 'real-time 5-second' data implies it's for current market snapshots, there's no mention of specific use cases, prerequisites, or comparisons to sibling tools like get_daily_market_trading_info or get_stock_daily_trading that might offer overlapping functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return fields but does not mention critical traits like whether the data is real-time or historical, update frequency, rate limits, authentication needs, or potential errors. This leaves significant gaps for a tool with rich output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by a bulleted list of return fields. Every sentence earns its place, though the bullet list is detailed but necessary for clarity. It avoids redundancy and is efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data, no annotations, and an output schema (implied by context signals), the description is partially complete. It explains the return values well but lacks behavioral context (e.g., data freshness, limitations). For a tool with no parameters and rich output, it meets minimum viability but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics by detailing the return fields, adding value beyond the schema. However, it could slightly improve by clarifying data formats (e.g., date format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get top 20 stocks') and resource ('by trading volume in the centralized market'), distinguishing it from siblings that focus on different data like abnormal stocks, block trades, or company-specific information. It precisely defines the scope and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as for real-time vs. historical data, or how it differs from other volume-related tools like 'get_daily_market_trading_info'. It lacks explicit context or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a read operation ('get', 'retrieves'), which implies non-destructive behavior, but doesn't disclose other traits like rate limits, authentication needs, or error handling. The description adds value by specifying the scope (yearly, by type and period) and return format, but lacks comprehensive behavioral details for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by elaboration and return details. It's efficiently structured with three sentences, but the second sentence slightly repeats the first, and the return section could be more concise. Overall, it's well-sized with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It clearly states the purpose, scope, and return format. However, it lacks usage guidelines and could better address behavioral aspects like data freshness or limitations, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate. A baseline of 4 is applied as it correctly avoids redundancy, though a 5 would require explicit confirmation of no parameters, which isn't provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get yearly issuance volume statistics for listed call/put warrants' and 'Retrieves annual statistics on warrant issuance volumes by type and period.' This specifies the verb ('get', 'retrieves'), resource ('yearly issuance volume statistics'), and scope ('listed call/put warrants', 'annual'). However, it doesn't explicitly differentiate from sibling tools like 'get_warrant_basic_info' or 'get_warrant_daily_trading', which focus on different aspects of warrants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare it to sibling tools such as 'get_warrant_basic_info' or 'get_warrant_daily_trading'. The agent must infer usage based on the purpose alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool's purpose but omits critical behavioral traits such as whether it's a read-only operation, if it requires authentication, rate limits, data freshness, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Obtain major shareholders information') and efficiently includes key details (ownership threshold, company type, input parameter). There is no wasted verbiage, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral transparency, it lacks sufficient context for safe and effective use, such as permissions or data constraints, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'code' by specifying it as a 'stock code' for a 'listed company', which clarifies its purpose beyond the schema's generic 'Code' title. With 0% schema description coverage and only one parameter, this compensation is effective, though it could detail format (e.g., ticker symbol conventions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Obtain'), resource ('major shareholders information'), and scope ('for a listed company based on its stock code'), with the additional detail 'over 10% ownership' that distinguishes it from generic shareholder tools. It precisely communicates what the tool does without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 among the many sibling tools (e.g., get_company_shareholder_meeting_announcements, get_company_ownership_and_control). It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the return format in detail (listing specific fields like date, prices, and volumes), which is helpful. However, it does not mention potential limitations such as data availability, rate limits, or error handling, leaving gaps in behavioral context for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: the first sentence states the purpose, followed by a bulleted list of return fields. Every sentence earns its place, with no redundant or verbose language, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple query with one parameter), the description is reasonably complete. It details the return fields comprehensively, and since an output schema exists, it need not explain return values further. However, it lacks usage guidelines and behavioral details like error conditions, which slightly reduces completeness for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the description compensates by specifying that the tool operates 'based on its stock code,' clarifying the parameter's purpose. It does not provide format details (e.g., code length or examples), but given the single parameter and the description's clarification, it adds meaningful value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtain daily trading information for a listed company stock based on its stock code.' It specifies the verb ('obtain'), resource ('daily trading information'), and scope ('listed company stock'), making it easy to understand what the tool does. However, it does not explicitly differentiate from sibling tools like 'get_stock_monthly_trading' or 'get_stock_yearly_trading', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the input parameter ('stock code') but does not specify prerequisites, constraints, or recommend other tools for related tasks (e.g., monthly or yearly data). This lack of contextual usage advice limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool's function but lacks details on output format, data freshness, rate limits, authentication needs, or error handling. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and criteria, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and an output schema exists, the description's focus on purpose is adequate. However, with no annotations and no details on output structure or behavioral traits, it lacks completeness for guiding an agent in practical use beyond the basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied since the schema fully covers the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('stocks') with precise criteria ('with no price change in the first five trading days'), making the purpose unambiguous. It effectively distinguishes this tool from siblings by focusing on a unique price stability metric, unlike tools that retrieve general trading data or company information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context for application, or compare it to sibling tools like 'get_stock_price_changes' or 'get_stock_daily_trading', leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes pagination behavior (page_size, page_number defaults and limits) and sorting capabilities (order_by fields, order_direction), which are useful behavioral details. However, it doesn't mention whether this is a read-only operation, what authentication might be required, rate limits, or what happens with invalid parameters. The description adds some behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with the core purpose, then provides a clear 'Args:' section with detailed parameter explanations. Every sentence earns its place by adding necessary information. The bilingual field explanations in order_by are particularly helpful. Minor improvement could be front-loading more behavioral context before the parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, financial data aggregation), no annotations, but with an output schema present, the description is reasonably complete. It thoroughly documents all parameters and their semantics. The output schema existence means the description doesn't need to explain return values. However, it could benefit from more behavioral context about the data source, update frequency, or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides extensive parameter semantics beyond what the input schema offers. With 0% schema description coverage, the description fully compensates by explaining all 4 parameters in detail: page_size (default, max), page_number (default, starting point), order_by (available fields with bilingual explanations), and order_direction (values, default). This adds crucial meaning that the bare schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get profitability analysis query summary table (all companies aggregate report).' It specifies the verb ('Get'), resource ('profitability analysis query summary table'), and scope ('all companies aggregate report'). However, it doesn't explicitly differentiate from its sibling 'get_company_profitability_analysis', which appears to be a similar tool for individual company analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions 'all companies aggregate report,' it doesn't clarify when to choose this aggregate view over individual company analysis tools like 'get_company_profitability_analysis' or other financial reporting tools in the sibling list. No explicit when/when-not instructions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool's behavior by specifying it returns comprehensive statistics in a formatted string, including details like industry categories and holding percentages, but lacks information on rate limits, data freshness, or error handling, which are important for a read-only statistical tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in the first sentence, followed by details on return values. It is appropriately sized with no redundant information, though the bulleted list could be slightly condensed for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0 parameters, and no output schema, the description provides a clear purpose and return format, but it lacks context on data sources, update frequency, or limitations, which could help the agent use it more effectively in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add parameter details, which is appropriate, earning a baseline score of 4 for not introducing unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('foreign and mainland China investment holding ratios by industry category'), distinguishing it from siblings by focusing on foreign investment statistics in the Taiwan stock market, unlike tools for trading info, company data, or market indices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While it implies usage for foreign investment statistics, it does not mention prerequisites, exclusions, or compare to similar tools like 'get_top_foreign_holdings', leaving the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds some behavioral context: 'Automatically detects company industry and uses appropriate financial statement format.' This explains adaptive formatting, which is useful. However, it lacks details on permissions, rate limits, data freshness, or error handling, leaving gaps for a tool that likely accesses financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by an additional behavioral detail. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, input semantics, and a key behavioral trait (automatic format detection). The output schema likely handles return values, so the description doesn't need to explain them. However, it could benefit from more context on limitations or sibling tool differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds meaning by specifying that the 'code' parameter is a 'stock code' for a 'public company', which clarifies its purpose beyond the generic schema. However, it does not explain format (e.g., ticker symbol conventions) or constraints, partially compensating but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtain balance sheet for a public company based on its stock code.' It specifies the verb ('obtain'), resource ('balance sheet'), and key input ('stock code'). However, it does not explicitly differentiate from sibling tools like 'get_company_balance_sheet', which might target non-public companies or have different scopes, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'public company' and 'stock code', suggesting it's for publicly traded entities. It does not provide explicit when-to-use guidance versus alternatives (e.g., 'get_company_balance_sheet' or other financial tools) or mention prerequisites like data availability or time periods, relying on implied understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns monthly trading information and lists the fields, but does not describe behavioral traits such as rate limits, error handling, authentication requirements, or whether the data is real-time or historical. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the purpose clearly, followed by a bulleted list of return fields. Every sentence earns its place, with no redundant or verbose language. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, but with an output schema implied by the return fields listed), the description is mostly complete. It explains what the tool does and what it returns, though it lacks behavioral context and usage guidelines. The presence of detailed return information compensates for the lack of an explicit output schema, making it adequate for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by specifying that the parameter 'code' is a 'stock code' for a 'listed company stock'. This adds meaningful context beyond the schema's minimal title ('Code'), clarifying the parameter's purpose and format. Since there is only one parameter, the description effectively covers its semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Obtain monthly trading information') and resource ('for a listed company stock based on its stock code'), distinguishing it from siblings like get_stock_daily_trading or get_stock_yearly_trading by specifying the monthly timeframe. It provides a concrete verb+resource combination that is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, constraints, or comparisons to sibling tools (e.g., get_stock_daily_trading for daily data or get_stock_yearly_trading for yearly data). The agent must infer usage from the name and description alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the automatic industry detection and format adaptation behavior, which is useful context beyond basic functionality. However, it does not cover other behavioral traits like permissions, rate limits, or response format, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence stating the core purpose and the second detailing the automatic behavior in a bulleted list. Every sentence adds value without waste, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is mostly complete. It explains the purpose, parameter semantics, and behavioral context (industry detection), but could improve by addressing usage guidelines or more behavioral details. The presence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'code' parameter is a stock code for a listed company, which is not covered in the schema (0% description coverage). This compensates well for the schema gap, though it does not detail format or validation rules for the code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('obtain comprehensive income statement') and resource ('listed company based on its stock code'), distinguishing it from sibling tools like get_company_balance_sheet or get_company_monthly_revenue by focusing on income statements. It also specifies the scope of automatic industry detection and format adaptation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for income statements of listed companies via stock codes, but does not explicitly state when to use this tool versus alternatives (e.g., get_public_company_income_statement) or any prerequisites. The context is clear but lacks explicit guidance on alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (including fields like Date, Code, Name, etc.), which is helpful. However, it doesn't mention behavioral traits such as data freshness (e.g., real-time vs. historical), rate limits, error handling, or authentication needs, leaving gaps in transparency for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the core purpose and followed by a clear bulleted list of return fields. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema (implied by the detailed return description), the description is mostly complete. It covers the purpose, parameter meaning, and return structure adequately. However, it lacks context on data sources or limitations, which could be useful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining that the 'code' parameter is a 'stock code' for a 'listed company stock.' This adds meaningful context beyond the schema's basic type definition, though it doesn't specify format constraints (e.g., length, pattern) or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Obtain') and resources ('P/E ratio, dividend yield, and P/B ratio for a listed company stock'), distinguishing it from siblings that focus on different financial metrics, trading data, or company information. It precisely identifies the three valuation ratios returned, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'based on its stock code,' which suggests it's for retrieving valuation data for a specific stock. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_valuation_ratios_by_date' or other financial data tools, leaving room for ambiguity in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns specific yearly trading data, which is useful, but it doesn't mention behavioral traits like whether it's read-only (implied by 'Obtain'), potential rate limits, error handling, or data freshness. The description adds basic context but lacks depth for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose in the first sentence, followed by a clear bulleted list of return values. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), no annotations, and the presence of an output schema (implied by the detailed return list), the description is mostly complete. It explains what the tool does and what it returns, but it could improve by adding usage context or behavioral details to fully guide the agent in a rich sibling environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the description clarifies that 'code' refers to a 'stock code' for a 'listed company stock,' adding meaningful semantics beyond the schema. However, it doesn't specify format details (e.g., length, allowed characters), so it doesn't fully compensate but provides good value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Obtain') and resource ('yearly trading information for a listed company stock'), and it distinguishes itself from siblings like 'get_stock_daily_trading' or 'get_stock_monthly_trading' by specifying the yearly timeframe, making it easy to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it's for 'yearly trading information,' which suggests it should be used when annual data is needed, but it doesn't explicitly say when to use this tool versus alternatives (e.g., daily or monthly tools) or provide any exclusions. This leaves some ambiguity for the agent in selecting among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a retrieval operation, which implies it is read-only and non-destructive, but does not explicitly state this or cover other behavioral traits like rate limits, authentication needs, or error handling. The description adds some context about event types but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement, followed by elaboration, and then structured sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which reduces the need to detail return values in the description), the description is largely complete. It covers purpose, parameter semantics, and return format, though it could improve by adding more behavioral context or usage guidelines relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the description compensates by explaining the 'top' parameter's semantics, including its default value (10) and behavior when empty or 0 (returns all events). This adds meaningful context beyond the schema's basic type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'Retrieves') and resources ('Taiwan Stock Exchange event announcements and activities'), including examples like seminars and training sessions. It distinguishes itself from sibling tools that focus on stocks, companies, or market data by specifically targeting TWSE-organized events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it retrieves events 'of interest to market participants and investors', but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. No sibling tools are mentioned for comparison, leaving usage guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes what data is retrieved (upcoming/historical schedules with detailed fields) and the filtering behavior with the optional code parameter. However, it doesn't mention potential limitations like date ranges, pagination, rate limits, authentication requirements, or data freshness that would be important for a financial data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose statement, detailed explanation, Args, Returns) and appropriately sized. Every sentence adds value, though the Returns section could be slightly more concise by grouping related fields or using bullet points more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but detailed output), the description is quite complete. It explains the purpose, parameter behavior, and return format in detail. The existence of an output schema means the description doesn't need to fully document return values, but it still provides a comprehensive overview of what data will be returned, making it sufficiently complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage (parameter 'code' has no description in schema), but the description's Args section provides excellent semantic context: explains it's a stock code, that it's optional, and the behavioral difference when provided (filters for specific company) versus when empty (returns all upcoming schedules). This fully compensates for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'Retrieves') and resources ('ex-dividend and ex-rights schedule for listed stocks'), including the scope of data (upcoming/historical dates, detailed corporate action information). It distinguishes itself from sibling tools by focusing specifically on dividend/rights schedules rather than other financial data like trading info, company profiles, or governance data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Essential for dividend investment strategies') and includes usage guidance in the Args section (explaining the optional 'code' parameter behavior). However, it doesn't explicitly state when NOT to use it or name specific alternative tools from the sibling list for different types of corporate action data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the return format in detail, which is helpful, but lacks behavioral traits such as rate limits, authentication needs, data freshness, or error handling. The description does not contradict annotations, but it misses key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a structured list of return fields. Every sentence earns its place, with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description is complete for a simple query tool. It explains what the tool does and what it returns. However, without annotations, it could benefit from more behavioral context like data sources or update frequency, but it's largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics, listing return fields. This adds value beyond the schema, though it's not about input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get stocks announced as notice stocks today') and distinguishes it from siblings by focusing on today's notice stocks, unlike tools like 'get_abnormal_accumulated_notice_stocks' or general trading tools. It specifies the resource (stocks) and temporal scope (today).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'today,' suggesting it's for current announcements. However, it does not explicitly state when to use this tool versus alternatives like 'get_abnormal_accumulated_notice_stocks' or other date-specific tools, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by specifying the exact return format (formatted string with 9 detailed fields) and the ranking scope (top 20). However, it lacks details on data freshness, potential rate limits, or error conditions, which would be helpful for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: the first sentence states the purpose, the second elaborates on return content, and the bulleted list details specific fields. Every sentence and bullet point earns its place by providing essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (ranking data with multiple fields), no annotations, and no output schema, the description does a good job of explaining what the tool returns. However, it could improve by mentioning data sources, update frequency, or any limitations, which would make it more complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics, listing the 9 return fields with their meanings. This adds significant value beyond the schema, though a baseline of 4 is given since no input parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get top 20 companies') and resource ('by foreign and mainland China investment holdings'), distinguishing it from sibling tools that focus on different financial data like trading stats, company profiles, or market indices. It precisely defines the scope and output content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving rankings of foreign holdings, but does not explicitly state when to use this tool versus alternatives like get_foreign_investment_by_industry or other investment-related tools. No exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it retrieves ranking statistics, specifies the data includes both individual stocks and ETFs, and details the return format. However, it doesn't mention potential limitations like data freshness, rate limits, or authentication needs. Since annotations are absent, the description adds substantial value but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the core purpose. Each sentence adds value: the first states the action, the second explains the data scope, the third provides usage context, and the fourth details the return format. There is no wasted text, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and an output schema exists, the description is complete. It fully explains the tool's purpose, output format, and usage context without needing to cover inputs or behavioral annotations. The presence of an output schema means the description doesn't need to detail return values beyond what's provided, and it adequately addresses all necessary aspects for a read-only ranking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing on output semantics instead. This compensates well for the lack of parameters, providing clear information on what the tool returns without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get top 10 securities by number of regular investment accounts (定期定額).' It specifies the verb ('Get'), resource ('securities'), and scope ('top 10'), distinguishing it from sibling tools like 'get_brokers_offering_regular_investment' by focusing on ranking rather than broker data. The additional context about retrieving ranking statistics for stocks and ETFs further clarifies its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it 'helps identify the most popular securities for systematic investment strategies,' suggesting it's for investment analysis. However, it lacks explicit guidance on when to use this tool versus alternatives, such as comparing to other ranking tools in the sibling list like 'get_top_20_volume_stocks' or 'get_top_foreign_holdings.' No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it specifies the tool retrieves daily closing info and statistics, outlines parameter defaults and constraints (e.g., count max of 50 for non-all categories), and describes output format options. However, it does not mention rate limits, authentication needs, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by a structured 'Args' section with bullet points for each parameter. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is largely complete: it covers purpose, parameters, and behavioral context. However, it lacks details on return values (e.g., data structure or examples) and does not address potential errors or side effects, which could be improved given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by detailing all three parameters: it explains 'category' with enum values and translations, 'count' with default and max limits, and 'format' with output options. This adds significant meaning beyond the basic schema, ensuring parameters are well-understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Obtain') and resource ('daily market closing information and overall market statistics'), distinguishing it from siblings like 'get_market_historical_index' or 'get_taiwan_50_index_history' by focusing on daily data across multiple index categories rather than historical or specific index data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving market index info, but does not explicitly state when to use this tool versus alternatives like 'get_market_historical_index' for historical data or 'get_taiwan_50_index_history' for a specific index. It provides parameter details that suggest context, but lacks direct guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates this is a read-only retrieval operation ('Retrieves statistics'), specifies the data granularity ('on each trading day'), and describes the return format in detail. However, it doesn't mention potential limitations like date range constraints, data freshness, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured: a clear purpose statement followed by elaboration and detailed return format. Every sentence adds value - no repetition or wasted words. The return format section is appropriately detailed given the lack of output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no annotations but with detailed return format documentation, this description is complete. It explains what the tool does, what data it provides, and the structure of returned information. The output format section compensates for the lack of output schema by clearly specifying the data fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what data is retrieved and returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get daily number of warrant traders'), resource ('warrant traders'), and scope ('daily'). It distinguishes from siblings like 'get_warrant_basic_info' or 'get_warrant_daily_trading' by focusing specifically on trader count statistics rather than general warrant information or trading data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('providing insights into warrant market participation levels') but doesn't explicitly state when to use this tool versus alternatives. No specific exclusions or prerequisites are mentioned, leaving the agent to infer appropriate usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It effectively describes the tool's behavior: it retrieves data (read operation), explains the filtering capability, and details the comprehensive return format. It doesn't mention rate limits, authentication needs, or data freshness, but provides substantial behavioral context for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the core purpose, but the detailed 'Returns' section listing 15 specific data points is quite lengthy. While informative, some of this detail might be better placed in an output schema. The structure is logical but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but has output schema), the description is remarkably complete. It covers purpose, usage, parameter semantics, and detailed return values. The presence of an output schema means the description doesn't need to explain return structure, yet it still provides valuable semantic context about what data is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter, but the description fully compensates by explaining the 'code' parameter in detail: 'Warrant code (optional). If provided, filters results for specific warrant. If empty, returns all warrant basic information.' This adds crucial semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get basic information of listed warrants' with specific details about what data is retrieved (warrant codes, types, exercise periods, underlying assets, etc.). It distinguishes itself from sibling tools by focusing specifically on warrants, while siblings cover stocks, companies, brokers, ETFs, and other financial instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Retrieves comprehensive basic data for all listed warrants' and explains the optional filtering capability. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools (like get_warrant_daily_trading or get_warrant_yearly_issuance_statistics).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it specifies the API returns news in Chinese with dates in a specific format (民國年), explains default behaviors for empty parameters, and notes the tool is for retrieval (implied read-only). It could improve by mentioning rate limits or authentication needs, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, details, args, note, returns) and front-loaded key information. It is appropriately sized, though the 'Returns' section could be slightly more concise, as some details might overlap with output schema (which exists).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with output schema), the description is complete. It covers purpose, usage, parameters, behavioral notes, and return format. The output schema existence means the description doesn't need to detail return values extensively, and it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by providing detailed parameter semantics. It explains both parameters (start_date, end_date) with format requirements (YYYYMMDD), default values, and usage rules (e.g., if both empty returns current month's news). This adds significant value beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('latest news from Taiwan Stock Exchange'), including scope ('with optional date filtering'). It distinguishes from siblings by focusing on news announcements rather than financial data, stocks, or company-specific information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (retrieving official news announcements including market updates, regulatory changes, etc.). However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, though the purpose naturally differentiates it from most siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses important behavioral traits: the API may return empty data when there are no warrant trades for the day, and it returns a formatted string with specific data fields. The description doesn't mention rate limits, authentication requirements, or data freshness, but provides reasonable behavioral context for a read-only data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (description, Args, Returns, Note), front-loading the core purpose. Every sentence adds value: the opening defines scope, Args explains parameter behavior, Returns documents output format, and Note provides important caveats. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single optional parameter, read-only data retrieval), the description provides complete context. It explains the tool's purpose, parameter usage, return format, and important behavioral notes. With an output schema present, the description appropriately focuses on semantics rather than repeating structured return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter, the description fully compensates by explaining the 'code' parameter's purpose, optional nature, and filtering behavior. It clearly states that an empty code returns all warrant trading data, which adds crucial semantics beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get daily trading data'), resource ('listed call/put warrants'), and scope ('daily trading volume and value statistics'). It distinguishes from sibling tools like 'get_warrant_basic_info' by focusing on trading data rather than basic information, and from 'get_stock_daily_trading' by specifying warrants rather than stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to retrieve daily trading statistics for warrants. It explicitly mentions checking 'warrant basic info' before querying trading data, which is helpful guidance. However, it doesn't specify when NOT to use this tool or name alternative tools for similar data types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a read-only retrieval tool (implied by 'Get'), provides daily data, includes filtering capability, returns formatted strings with specific fields, and has limitations (no speaker/contact details). It also references an alternative for complete information, adding useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently front-loaded. The first sentence states the core purpose, followed by elaboration on importance and filtering. The Args and Returns sections are clearly labeled, and the Note provides essential limitations without redundancy. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with output schema), the description is complete. It covers purpose, usage, parameter semantics, return format details, and limitations. The output schema existence means the description doesn't need to explain return values exhaustively, and it adequately addresses the gaps in schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its single parameter, so the description must compensate. It fully explains the 'code' parameter: it's optional, filters results by company stock code, and returns all announcements if empty. This adds crucial meaning beyond the bare schema, making the parameter's purpose and behavior clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get daily major announcements from listed companies.' It specifies the resource (major announcements) and distinguishes itself from siblings by focusing on material disclosures that impact stock prices, unlike other tools that handle trading data, financial statements, or governance information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it retrieves announcements that 'may impact stock prices and investor decisions' and can filter by company code or get all announcements. It also notes an alternative for contact details. However, it doesn't explicitly state when not to use this tool versus specific sibling tools like get_company_shareholder_meeting_announcements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![TWSEMCPServer MCP server](https://glama.ai/mcp/servers/twjackysu/TWSEMCPServer/badges/card.svg)](https://glama.ai/mcp/servers/twjackysu/TWSEMCPServer)

Score Badge

Copy to your README.md:

[![TWSEMCPServer MCP server](https://glama.ai/mcp/servers/twjackysu/TWSEMCPServer/badges/score.svg)](https://glama.ai/mcp/servers/twjackysu/TWSEMCPServer)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/twjackysu/TWSEMCPServer'

If you have feedback or need assistance with the MCP directory API, please join our Discord server