VNStock 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 have distinct purposes targeting specific data types (e.g., balance sheets vs. cash flows vs. price history), but there is some potential confusion between 'get_all_symbols', 'get_all_symbols_by_group', and 'get_all_symbols_by_industry' as they all retrieve symbol lists with minor filtering differences. The descriptions help clarify, but the overlap exists.
Naming Consistency5/5
All tools follow a consistent 'verb_noun' pattern with snake_case, using 'get_' for retrieval, 'list_' for listing, and 'search_' for searching. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
Tool Count3/5
With 33 tools, the count is borderline high for a stock market server, potentially overwhelming for agents. While it covers many aspects (symbols, financials, news, funds, etc.), it might benefit from consolidation or categorization to reduce complexity, as 16-25 tools would be more typical for such a scope.
Completeness5/5
The tool set provides comprehensive coverage for a stock market domain, including symbol retrieval, financial statements (balance sheets, income statements, cash flows), company details (overview, news, events), pricing data (history, intraday, depth), funds, and ancillary data like exchange rates and gold prices. There are no obvious gaps, offering full lifecycle and data access for typical stock analysis workflows.
Average 3/5 across 33 of 33 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
With no annotations provided, the description carries full burden but offers minimal behavioral information. It mentions the return type options but doesn't disclose whether this is a read-only operation, if there are rate limits, authentication requirements, or what 'all symbols' actually means in scope. The description is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but poorly structured - it starts with an unclear purpose statement, then provides parameter documentation. While concise, the front-loading is ineffective due to the vague opening. The information about returns is useful but could be better integrated.
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 unclear purpose relative to siblings, the description is inadequate. It covers the parameter but fails to explain what the tool actually returns (what 'symbols' means, what data fields are included, how industries relate to symbols) or when to use it versus similar 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 description provides clear parameter information for the single parameter 'output_format', explaining the two possible values and their return types. With 0% schema description coverage and only one parameter, this adequately compensates for the schema gap, though it doesn't explain why one format might be preferred over the other.
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 states 'Get all symbols from stock market' which is a tautology of the tool name 'get_all_industries' - it doesn't clarify what 'industries' means or how it relates to symbols. It fails to distinguish this tool from sibling tools like 'get_all_symbols' or 'get_all_symbols_by_industry', leaving the purpose ambiguous.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_all_symbols' or 'get_all_symbols_by_industry'. The description offers no context about appropriate use cases or exclusions, making it impossible for an agent to make informed decisions.
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 the return type ('pd.DataFrame') but doesn't describe what 'symbol groups' are, how the data is structured, whether it's a read-only operation, potential rate limits, or any authentication requirements. The description is minimal and lacks essential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but structured with sections for 'Args' and 'Returns'. However, it includes redundant information (e.g., stating 'pd.DataFrame' in the Returns section when the output schema is false) and lacks front-loaded clarity about the tool's core purpose. It could be more efficiently organized to prioritize key details.
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 (retrieving financial data), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'symbol groups' are, how the data is returned, or any behavioral traits like error handling or data freshness. For a tool with potential nuances in financial contexts, this is inadequate.
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 some value by explaining the 'output_format' parameter with its enum values and default, which isn't covered in the schema (0% coverage). However, it doesn't elaborate on what 'symbol groups' means or provide context for the parameter beyond basic syntax. With one parameter and low schema coverage, the description partially compensates but remains basic.
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 ('all symbol groups from stock market'), making the purpose understandable. It distinguishes from siblings like 'get_all_symbols' by focusing on groups rather than individual symbols. However, it doesn't explicitly differentiate from 'get_all_symbols_by_group' which might be related.
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 doesn't mention when this tool is appropriate compared to siblings like 'get_all_symbols' or 'get_all_symbols_by_group', nor does it specify any prerequisites or contextual constraints 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type (pd.DataFrame) but lacks critical details like whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. For a data retrieval tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but structured with sections for Args and Returns. However, the first sentence is vague ('from stock market'), and the formatting is inconsistent (mixing str/Literal notation with plain text). It could be more front-loaded with clearer purpose.
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 low schema description coverage (0%), the description is incomplete. It misses behavioral context (e.g., safety, performance), detailed parameter semantics, and doesn't clarify the relationship to sibling tools. For a 2-parameter tool in a financial data context, this leaves significant 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?
Schema description coverage is 0%, so the description must compensate. It documents both parameters ('group' and 'output_format') and provides the return type, but doesn't explain what 'group' means (e.g., sector, exchange) or the implications of choosing 'json' vs 'dataframe'. This adds some value but leaves key semantics unclear.
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 symbols') and resource ('from stock market'), with the 'by group' qualifier indicating filtering. However, it doesn't explicitly differentiate from sibling tools like 'get_all_symbols' or 'get_all_symbols_by_industry', 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?
No guidance is provided on when to use this tool versus alternatives like 'get_all_symbols' or 'get_all_symbols_by_industry'. The description only states what it does, not when it's appropriate.
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 the return type (pd.DataFrame) and output format options, but doesn't cover critical aspects like rate limits, authentication needs, data freshness, error handling, or whether it's a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 purpose clearly, followed by structured Args and Returns sections. It avoids unnecessary fluff, though the formatting could be slightly more polished (e.g., using bullet points). Every sentence earns its place by conveying 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 no annotations, 0% schema coverage, and no output schema, the description is moderately complete. It covers purpose, parameters, and return type, but lacks details on behavioral traits, error cases, and deeper parameter semantics. For a financial data tool with 2 parameters, it's adequate but has clear gaps that could hinder effective use by 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying 'symbol: str' and 'output_format: Literal['json', 'dataframe'] = 'json'', explaining parameter types and default values. However, it doesn't clarify what 'symbol' represents (e.g., stock ticker), valid formats, or constraints, leaving some ambiguity. With 0% coverage, this provides basic but incomplete semantic context.
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 company dividends from stock market' specifies the verb ('Get') and resource ('company dividends'), distinguishing it from siblings like get_balance_sheets or get_income_statements. However, it doesn't explicitly differentiate from tools like get_company_events or get_company_trading_stats that might also involve company data, so it's not fully sibling-distinctive.
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 (e.g., for financial analysis), or compare to siblings like get_company_ratio_summary or get_company_reports. Usage is implied by the purpose but lacks explicit when/when-not 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 mentions the return type (pd.DataFrame) but lacks critical behavioral details: whether this is a read-only operation, if it requires authentication, rate limits, data freshness, or error handling. For a financial data tool with zero annotation coverage, this 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.
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 Args and Returns sections. Every sentence adds value, though the formatting could be slightly improved for readability (e.g., bullet points).
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 0% schema description coverage, the description is incomplete. It covers parameters but misses behavioral context (e.g., safety, performance) and doesn't fully explain return values beyond the type. For a tool fetching financial data, more guidance is needed.
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 compensates by documenting both parameters: 'symbol' (with type 'str') and 'output_format' (with enum values and default). However, it doesn't explain what 'symbol' represents (e.g., stock ticker) or the implications of choosing 'json' vs 'dataframe', 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 'Get' and resource 'company insider deals from stock market', which is specific and actionable. However, it doesn't distinguish this tool from potential siblings like get_company_officers or get_company_shareholders that might also provide insider-related data, keeping it from 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 available (e.g., get_company_overview, get_company_news), there's no indication of context, prerequisites, or exclusions for selecting this specific tool for insider deals.
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 the return type (pd.DataFrame) and output format options, it doesn't describe important behavioral aspects: whether this is a read-only operation, what data sources are used, rate limits, authentication requirements, error conditions, or pagination behavior beyond the page/page_size parameters. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections (Args, Returns) and uses minimal verbiage. Every sentence serves a purpose: stating the tool's function, documenting parameters, and specifying return type. However, the formatting with quotes and line breaks could be cleaner, and the purpose statement could be more front-loaded.
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 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. While it documents parameters and return type, it lacks crucial context: what 'company news' includes (headlines, dates, sources?), how results are ordered, error handling, data freshness, or relationship to sibling tools. The agent would struggle to use this tool effectively without trial and error.
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 explicitly lists all 4 parameters with their types and defaults, which adds significant value since schema description coverage is 0%. However, it doesn't explain parameter semantics beyond basic typing: what constitutes a valid 'symbol', what 'page_size' and 'page' actually control (e.g., pagination of news items), or what the output_format choice entails. The parameter documentation is present but lacks contextual meaning.
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 company news from stock market' - a specific verb ('Get') and resource ('company news') with domain context ('stock market'). It distinguishes itself from siblings like get_company_overview or get_company_events by focusing specifically on news. However, it doesn't explicitly contrast with these siblings in the description text itself.
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 (get_company_overview, get_company_events, etc.), there's no indication of what distinguishes news from other company information, when news is preferable to other data sources, or any prerequisites for using this 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type (pd.DataFrame) but doesn't describe what data the officers contain, whether this is a read-only operation, potential rate limits, authentication needs, or error conditions. For a data retrieval 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections for Args and Returns. Each sentence serves a purpose: stating the tool's function, documenting parameters, and specifying the return type. While concise, it could be slightly more front-loaded with the core purpose before parameter details.
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 (3 parameters, no output schema, no annotations), the description is partially complete. It covers the basic purpose and parameters adequately but lacks behavioral context, usage guidance, and details about the returned DataFrame structure. For a financial data tool that likely has specific constraints or data formats, more completeness would be beneficial.
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 explicitly documents all three parameters with their types and default values, which is valuable since schema description coverage is 0%. It explains what 'filter_by' does (working/all/resigned) and the output_format options. However, it doesn't provide deeper context about what 'symbol' format is expected (ticker symbol, exchange prefix, etc.) or what 'working' versus 'resigned' officers mean in practice.
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 company officers from stock market' - a specific verb ('Get') and resource ('company officers') with domain context ('stock market'). It distinguishes itself from siblings like get_company_overview or get_company_shareholders by focusing specifically on officers. However, it doesn't explicitly differentiate from potential similar tools not in the sibling list.
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, when this tool is appropriate compared to other company information tools in the sibling list, or any limitations. The agent must infer usage from the tool name and parameters 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 for behavioral disclosure. It mentions the return type (pd.DataFrame) but doesn't describe what data the overview contains, whether it's real-time or historical, any rate limits, authentication requirements, or error conditions. For a stock market data 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections for Args and Returns. Each sentence serves a purpose: stating the tool's function, documenting parameters, and specifying return type. While it could be slightly more concise by combining lines, there's minimal wasted verbiage and good front-loading of the core purpose.
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 stock market data tool with 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'company overview' actually includes (financial metrics? business description? stock performance?), doesn't mention data sources or freshness, and provides minimal behavioral context. The return type mention helps but doesn't substitute for proper output documentation.
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 documents both parameters (symbol and output_format) with their types and default values, which adds meaningful semantics beyond the bare schema. However, it doesn't explain what constitutes a valid symbol format (e.g., ticker conventions) or clarify the practical difference between json and dataframe output formats beyond type names.
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 company overview') and resource ('from stock market'), making the purpose understandable. It distinguishes this tool from siblings like get_balance_sheets or get_income_statements by focusing on a general overview rather than specific financial statements. However, it doesn't explicitly differentiate from tools like get_company_ratio_summary or get_company_trading_stats that might provide overlapping summary 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_company_ratio_summary, get_company_trading_stats), there's no indication of what makes this 'overview' distinct or when it should be preferred over other company data tools. The agent must 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type ('pd.DataFrame') but does not describe key behaviors like whether this is a read-only operation, potential rate limits, authentication needs, or what happens with invalid symbols. The description is minimal and misses 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections for Args and Returns, making it easy to parse. It is concise with no wasted words, though the front-loading could be improved by starting with a more detailed purpose statement before listing parameters.
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, no annotations, and no output schema, the description is incomplete. It lacks details on return format (e.g., structure of the DataFrame), error handling, or examples, making it inadequate for an AI agent to use effectively 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 description lists parameters ('symbol', 'output_format') and their types, adding basic semantics beyond the input schema, which has 0% description coverage. However, it does not explain what 'symbol' represents (e.g., stock ticker) or the implications of 'output_format' choices, leaving gaps in understanding despite compensating somewhat for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('company ratio summary from stock market'), making the purpose understandable. It distinguishes itself from siblings like 'get_finance_ratios' by specifying 'summary' and 'company' focus, though it could be more explicit about what 'ratio summary' entails compared to other financial 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 like 'get_finance_ratios' or 'get_company_overview'. The description lacks context about prerequisites, such as needing a valid stock symbol, or comparisons to sibling tools for financial data retrieval.
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 return type ('pd.DataFrame') but doesn't disclose behavioral traits like data source, rate limits, authentication needs, or what 'company reports' entail (e.g., financial statements, summaries). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and structured with sections for Args and Returns, making it easy to scan. However, the title is null, and the core purpose statement could be more front-loaded; currently, it's a single sentence followed by details.
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 low schema coverage, the description is incomplete. It lacks details on what 'company reports' include, how they differ from sibling tools, and behavioral aspects like data freshness or error handling, making it inadequate for a tool in a complex financial 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?
Schema description coverage is 0%, so the description must compensate. It lists parameters and their types, adding value beyond the bare schema. However, it doesn't explain what 'symbol' represents (e.g., stock ticker) or clarify the meaning of 'output_format' options, leaving semantics partially unclear.
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 ('company reports from stock market'), making the purpose understandable. However, it doesn't differentiate what type of reports these are compared to siblings like 'get_balance_sheets' or 'get_income_statements', which are more specific report types.
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 financial data (e.g., get_balance_sheets, get_company_overview), the description lacks context on what makes 'company reports' distinct or when they should be preferred over other report-specific 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 mentions the return type (pd.DataFrame) but lacks critical details like whether this is a read-only operation, potential rate limits, authentication needs, or what happens with invalid symbols. The description is minimal and misses key behavioral traits.
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 brief and structured with clear sections for Args and Returns, making it easy to parse. It avoids unnecessary fluff, though the title 'null' is redundant and could be omitted for better efficiency.
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 low schema coverage, the description is incomplete. It covers basic parameters and return type but omits error handling, data freshness, source details, and how results are structured (e.g., columns in the DataFrame). For a financial data tool, this leaves significant gaps in 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?
Schema description coverage is 0%, so the description must compensate. It lists both parameters (symbol and output_format) and explains output_format's options and default, adding value beyond the schema. However, it doesn't clarify what 'symbol' represents (e.g., stock ticker format) or provide examples, 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 verb 'Get' and the resource 'company shareholders from stock market', making the purpose specific and understandable. It distinguishes itself from siblings like get_company_officers or get_company_subsidiaries by focusing on shareholders, 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. While the description implies it's for retrieving shareholder data, it doesn't specify prerequisites, limitations, or when other tools like get_company_overview might be more appropriate, leaving usage context 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 mentions the return type (pd.DataFrame) but doesn't cover critical aspects like data source reliability, rate limits, error handling, or whether it's a read-only operation. The description is minimal and misses key behavioral traits needed for safe invocation.
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, followed by parameter and return details in a structured format. It's efficient with minimal waste, though the lack of usage context slightly reduces its effectiveness. Every sentence serves a purpose, but it could be more comprehensive.
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 (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain return values beyond 'pd.DataFrame' (e.g., column meanings), error cases, or dependencies. For a tool with financial data retrieval, more context on data freshness and limitations is needed.
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 lists parameters (symbol, filter_by, output_format) and their types, adding some meaning beyond the schema. However, it doesn't explain what 'symbol' represents (e.g., stock ticker), the difference between 'all' and 'subsidiary' filters, or the implications of output formats, leaving gaps in 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 ('Get') and resource ('company subsidiaries from stock market'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like get_company_overview or get_company_shareholders, which might also retrieve company-related data but for different aspects.
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 lacks context such as prerequisites (e.g., valid stock symbols), comparison to siblings (e.g., use this for subsidiary data vs. get_company_overview for general info), or exclusions (e.g., not for historical 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 full burden. It mentions the return type 'pd.DataFrame' and output formats, but lacks details on permissions, rate limits, data freshness, or error handling. For a tool fetching trading stats, this is a significant gap in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by structured Args and Returns sections, making it efficient. However, the 'Returns' section could be integrated more smoothly, and some redundancy exists (e.g., stating 'pd.DataFrame' when output_format includes it).
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, no output schema, and low schema coverage, the description is moderately complete. It covers basic parameters and return type but misses details on data scope, time ranges, or error cases, which are important for a trading stats tool in a context with many financial data siblings.
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 value by explaining 'symbol' as a string and 'output_format' with its enum values and default. However, it doesn't clarify what 'symbol' represents (e.g., ticker symbol) or the implications of choosing 'json' vs 'dataframe', 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 verb 'Get' and the resource 'company trading stats from stock market', making the purpose evident. However, it doesn't differentiate from sibling tools like 'get_company_overview' or 'get_price_board', which might also retrieve stock market data, so it's not fully specific to 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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for company data (e.g., 'get_company_overview', 'get_quote_history_price'), the description lacks context on what makes this tool unique or when it's appropriate, offering only basic usage without exclusions or comparisons.
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 mentions the return type ('pd.DataFrame') but doesn't describe what data the DataFrame contains, whether there are rate limits, authentication requirements, or potential errors. For a financial data 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three clear sections: purpose statement, arguments, and returns. Each sentence serves a distinct purpose without redundancy. The structure with labeled sections ('Args:', 'Returns:') aids readability, though it could be more front-loaded with the core purpose.
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 2 parameters with 0% schema coverage and no output schema, the description provides basic parameter documentation and return type but lacks details on data format, error conditions, and behavioral constraints. For a financial data retrieval tool with multiple sibling alternatives, this leaves the agent with incomplete context about what exactly is returned and how it differs from similar 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?
Schema description coverage is 0%, so the description must compensate. It documents both parameters: 'symbol' (fund symbol) and 'output_format' (with enum values and default). However, it doesn't explain symbol format requirements, what 'dataframe' output entails versus 'json', or provide examples. The description adds basic semantics but doesn't fully compensate for the schema 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 tool's purpose: 'Get asset holding of a fund from stock market' - this specifies the verb ('Get'), resource ('asset holding'), and domain ('fund from stock market'). It distinguishes from siblings like 'get_fund_industry_holding' or 'get_fund_top_holding' by focusing on general asset holdings rather than specific breakdowns. However, it doesn't explicitly contrast with these 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?
The description provides no guidance on when to use this tool versus alternatives. While it's clear this retrieves fund asset holdings, there's no mention of when to choose this over 'get_fund_industry_holding' or 'get_fund_top_holding', nor any prerequisites or context for usage. The agent must 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type 'pd.DataFrame' but does not explain what 'industry holding' entails (e.g., data structure, timeframes, or limitations like rate limits or authentication needs). This leaves significant gaps in understanding the tool's behavior beyond basic input-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 front-loaded with the core purpose, followed by structured Args and Returns sections, making it efficient and easy to parse. It avoids unnecessary verbosity, though minor improvements in clarity (e.g., explaining 'industry holding' briefly) could enhance it further.
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 tools, no annotations, and no output schema, the description is moderately complete. It covers basic input parameters and return type but lacks details on output structure, error handling, or integration with sibling tools, making it sufficient for minimal use but with clear gaps for robust agent operation.
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 meaning by specifying 'symbol' as 'symbol of the fund to get industry holding' and 'output_format' with options and default, which clarifies beyond the bare schema. However, it does not fully detail parameter constraints or examples, resulting in an adequate but incomplete enhancement.
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 'industry holding of a fund from stock market', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_fund_asset_holding' or 'get_fund_top_holding', which might have overlapping or related functions, 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_fund_asset_holding' or 'get_fund_top_holding' from the sibling list. It lacks context about use cases, prerequisites, or exclusions, leaving the agent without clear 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?
No annotations are provided, so the description carries full burden. It mentions the return type ('pd.DataFrame') which is helpful, but doesn't disclose important behavioral traits: whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what happens with invalid symbols. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured with clear sections (Args, Returns). The purpose statement is front-loaded, and each sentence serves a purpose. However, the formatting with quotes and line breaks could be cleaner, and the 'Returns: pd.DataFrame' contradicts the output_format parameter's default of 'json', creating some confusion.
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, 0% schema description coverage, and no output schema, the description is incomplete. While it mentions the return type, it doesn't explain the NAV report structure, data fields, or what 'nav report' actually contains. For a financial data tool with many sibling alternatives, more context about the specific data returned would be necessary for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 provides basic type information for parameters ('symbol: str', 'output_format: Literal['json', 'dataframe']') and a default value, which adds meaning beyond the bare schema. However, it doesn't explain what 'symbol' represents (ticker symbol? fund identifier?), acceptable formats, or constraints. The description adds some value but doesn't fully compensate for the 0% 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 tool's purpose: 'Get nav report of a fund from stock market' - a specific verb ('Get') and resource ('nav report of a fund'), with context about the data source ('from stock market'). It distinguishes from siblings like 'get_fund_asset_holding' or 'get_fund_top_holding' by focusing on NAV reports specifically. However, it doesn't explicitly differentiate from all siblings, keeping it at 4 rather than 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. With many sibling tools available (like 'get_fund_asset_holding', 'get_fund_industry_holding', 'list_all_funds'), there's no indication of when this specific NAV report tool is appropriate versus other fund-related tools. The description only states what it does, not when to choose it.
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 the return type (pd.DataFrame) and output format options, but lacks critical behavioral details such as data source, rate limits, authentication needs, error handling, or whether it's a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 front-loaded with the purpose, followed by parameter and return details in a structured format. However, the 'Returns: pd.DataFrame' contradicts the output_format options (json/dataframe), creating confusion. The structure is efficient but marred by this inconsistency.
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 0% schema description coverage, the description is incomplete. It covers basic purpose and parameters but misses behavioral context, error handling, and clear return value explanation. For a tool with two parameters and financial data, more detail is needed to ensure proper 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'symbol' is the fund symbol and 'output_format' controls the return format with default 'json', which clarifies beyond the bare schema. However, it doesn't detail format specifics or constraints, 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 tool's purpose: 'Get top holding of a fund from stock market' with a specific verb ('Get') and resource ('top holding of a fund'), distinguishing it from sibling tools like get_fund_asset_holding or get_fund_industry_holding. However, it doesn't explicitly differentiate from get_fund_nav_report or list_all_funds, which could be related but serve different purposes.
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 sibling tools like get_fund_asset_holding or get_fund_industry_holding, nor does it specify prerequisites or context for usage. The agent must infer 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.
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 'Get's data, implying a read-only operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, data freshness, or error handling. The description is minimal and fails to add meaningful context 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 appropriately sized and front-loaded with the core purpose, followed by parameter and return details in a structured format. Every sentence earns its place, though the return statement could be integrated more smoothly. It avoids unnecessary verbosity.
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 low schema description coverage (0%), the description is incomplete. It doesn't explain what a 'price board' returns (e.g., specific fields like price, change, volume) or behavioral aspects like data sources or limitations. For a tool with parameters and financial data retrieval, 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.
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 lists parameters 'symbols' and 'output_format' with types and a default, adding some semantics beyond the bare schema. However, it doesn't explain what 'price board' includes (e.g., current prices, volumes) or constraints on symbols, 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 'Get' and resource 'price board from stock market', which is specific and unambiguous. However, it doesn't differentiate from sibling tools like get_quote_history_price or get_quote_intraday_price, which also retrieve price-related data, so it doesn't fully distinguish its scope from 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?
The description provides no guidance on when to use this tool versus alternatives like get_quote_history_price or get_quote_intraday_price. It lacks context about what a 'price board' entails compared to other price-related tools, offering no explicit when/when-not instructions or prerequisites.
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 the return type ('pd.DataFrame') but doesn't explain what 'price depth' means (e.g., bid-ask spreads, order book data), whether there are rate limits, authentication requirements, or data freshness. For a financial data 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args and Returns, and it's concise with no wasted words. However, the title is null, and the purpose statement could be more front-loaded with specifics about 'price depth' to improve immediate clarity.
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 0% schema description coverage, the description is incomplete. It lacks details on what 'price depth' returns (e.g., structure of the DataFrame), error handling, data sources, or usage constraints. For a tool with 2 parameters in a financial context, this leaves too much undefined for reliable 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%, so the description must compensate. It lists both parameters with types and a default for 'output_format', adding value beyond the bare schema. However, it doesn't explain what 'symbol' entails (e.g., ticker format, exchange codes) or clarify the difference between 'json' and 'dataframe' outputs, 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 ('Get quote price depth') and resource ('from stock market'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_quote_history_price' or 'get_quote_intraday_price' which also retrieve price-related data, leaving some ambiguity about what specifically 'price depth' means compared to other quote 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 multiple sibling tools for quotes (e.g., 'get_quote_history_price', 'get_quote_intraday_price'), the description lacks context on what 'price depth' entails and when it's appropriate compared to other quote retrieval methods, 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 full burden but only mentions return types (pd.DataFrame or json). It doesn't disclose behavioral traits such as rate limits, authentication needs, data freshness, or what 'all symbols' entails (e.g., scope, exclusions). This is inadequate for a tool with potential complexity.
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 brief but front-loaded with the core purpose. However, the formatting with 'Args:' and 'Returns:' sections is slightly verbose for such a simple tool, and it could be more streamlined without losing 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 no annotations, no output schema, and low schema coverage, the description partially compensates by explaining the parameter and return types. However, it lacks details on behavioral aspects and doesn't fully address the tool's complexity in retrieving 'all symbols', making it minimally adequate 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 description explicitly documents the single parameter 'output_format' with its options and default, adding meaning beyond the input schema which has 0% description coverage. Since there's only one parameter and it's fully covered in the description, this compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 symbols from stock market', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_all_symbols_by_group' or 'get_all_symbols_by_industry', 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 like the sibling tools for filtered symbol retrieval. It lacks any context about use cases, prerequisites, or comparisons to other tools in the server.
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 mentions what data is retrieved but lacks critical behavioral information: no indication of data freshness, rate limits, authentication requirements, error conditions, or what happens with invalid symbols. The return format is mentioned but without details about structure or content.
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 for Args and Returns, making it easy to parse. It's appropriately sized for a 3-parameter tool, though the main description sentence could be more specific about what balance sheet data includes.
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 financial data retrieval tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks information about data sources, update frequency, error handling, authentication needs, and detailed return structure. The mention of pd.DataFrame in Returns is helpful but insufficient without schema 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?
The description provides meaningful semantic context for all three parameters beyond the schema's 0% coverage. It explains that 'symbol' represents the company symbol, 'period' controls the reporting period, and 'output_format' determines the return format. This adds significant value over the bare schema, though it doesn't elaborate on format differences or period implications.
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 'balance sheets of a company from stock market', making the purpose specific and understandable. It distinguishes from some siblings like 'get_income_statements' by specifying balance sheets, but doesn't explicitly differentiate from all financial data tools in the sibling list.
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 about when to use this tool versus alternatives. The description doesn't mention when this tool is appropriate compared to other financial data tools in the sibling list, nor does it provide any context about prerequisites or typical use cases.
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 mentions the return type (pd.DataFrame) but omits critical details like data source reliability, rate limits, authentication needs, error handling, or whether this is a read-only operation. For a financial data tool with zero annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (Args, Returns) but includes redundant information (e.g., repeating defaults already in schema) and could be more front-loaded. The first sentence states the purpose, but subsequent details could be trimmed 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, no output schema, and 3 parameters with 0% schema coverage, the description is moderately complete. It covers parameters and return type but lacks behavioral context (e.g., data freshness, limitations) and doesn't fully address the tool's complexity in a financial data 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 description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose (symbol, period, output_format) and provides type hints and defaults, compensating well for the schema's lack of descriptions. However, it doesn't clarify semantic nuances like symbol format requirements.
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 cash flows') and resource ('of a company from stock market'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from similar siblings like get_balance_sheets or get_income_statements, 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 like get_balance_sheets or get_income_statements. It lacks context about use cases, prerequisites, or exclusions, offering only basic parameter documentation.
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 pagination (page_size, page) and output format options, which is useful, but lacks critical details like rate limits, authentication needs, error handling, or what constitutes a 'company event' (e.g., earnings, splits, mergers). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 structured with 'Args:' and 'Returns:' sections, making it easy to parse, but it's slightly verbose for its content. The sentence 'Get company events from stock market' is front-loaded, but the parameter details could be more succinct. Overall, it's adequate but not optimally concise.
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 and no output schema, the description partially covers parameters and hints at pagination and output format, but it's incomplete. It doesn't explain the return value 'pd.DataFrame' in context (e.g., structure, columns) or address potential complexities like error cases. For a tool with 4 parameters and financial data, more context on behavior and outputs would be beneficial.
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 lists all parameters with types and defaults, adding clear semantics beyond the schema (which has 0% description coverage). It explains 'symbol' as a string, 'page_size' and 'page' for pagination, and 'output_format' with allowed values, effectively compensating for the schema's lack of descriptions. However, it doesn't clarify the meaning of 'page=0' (e.g., zero-indexed) or provide examples for 'symbol'.
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 'company events from stock market', which is specific and actionable. However, it doesn't distinguish this tool from sibling tools like 'get_company_news' or 'get_company_reports', which might also retrieve company-related information, leaving some ambiguity about what type of 'events' are being retrieved.
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 company data (e.g., get_company_news, get_company_reports), there's no indication of what makes 'events' unique or when to prefer this tool over others, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type ('pd.DataFrame') and output formats, but lacks critical information such as data sources, rate limits, authentication requirements, error handling, or whether this is a read-only operation. For a financial data 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with clear sections (Args, Returns), but could be more front-loaded. The first sentence states the purpose, but the parameter explanations are somewhat redundant with the schema (though necessary given 0% schema coverage). The structure is functional but not optimal for quick scanning.
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 retrieval with 3 parameters and no output schema, the description is moderately complete. It covers the basic purpose and parameters but lacks details about the returned finance ratios (what metrics, units, time periods), data freshness, or error cases. Without annotations or output schema, more context about the tool's behavior would be helpful.
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 substantial value beyond the input schema, which has 0% description coverage. It explains that 'symbol' is the company symbol, 'period' can be 'quarter' or 'year', and 'output_format' can be 'json' or 'dataframe'. This compensates well for the schema's lack of descriptions, though it doesn't elaborate on what specific finance ratios are returned or their format.
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 finance ratios of a company from stock market'. It specifies the verb ('Get'), resource ('finance ratios'), and source ('stock market'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_company_ratio_summary' or 'get_company_overview', which might provide similar financial 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. It doesn't mention sibling tools like 'get_company_ratio_summary' or explain what distinguishes this tool from others that might provide financial ratios or summaries. The user is left to infer usage based on the tool name and parameters 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. While it mentions the return type (pd.DataFrame), it doesn't describe authentication needs, rate limits, data freshness, error conditions, or what happens with invalid symbols. For a financial data 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with clear sections (Args, Returns). However, the first sentence is somewhat redundant with the tool name, and the structure could be more front-loaded with key usage information. The parameter explanations are efficient but the overall flow could be improved for quick scanning.
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 (financial data retrieval with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers basic parameter semantics and return type but lacks behavioral context, error handling, data source details, and comparison with sibling tools. The absence of output schema means the description should ideally explain the DataFrame structure more thoroughly.
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 substantial value beyond the input schema, which has 0% description coverage. It explains that 'symbol' is the company symbol, 'period' can be quarter or year with a default, and 'output_format' controls the return format. This compensates well for the schema's lack of descriptions, though it doesn't elaborate on symbol format requirements or period implications.
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 ('income statements of a company from stock market'), making the purpose specific and understandable. It distinguishes this tool from siblings like get_balance_sheets and get_cash_flows by focusing on income statements specifically. However, it doesn't explicitly contrast with other financial data tools beyond the name difference.
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_balance_sheets, get_cash_flows, get_company_overview), there's no indication of when income statements are appropriate versus other financial data. No prerequisites, exclusions, or contextual recommendations 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return type ('pd.DataFrame') and output format options, but doesn't describe pagination behavior (despite having a 'page_size' parameter), rate limits, authentication requirements, data freshness, or error conditions. For a financial data tool with 4 parameters, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear structure: purpose statement followed by parameter explanations. However, it includes redundant information - the return type 'pd.DataFrame' is mentioned in both the description body and the 'Returns' section. The formatting with 'Args:' and 'Returns:' sections is helpful but could be more integrated.
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 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description does an adequate job explaining parameters and return format. However, it lacks important context about data source, update frequency, limitations (e.g., which markets/exchanges are supported), and error handling. For a financial data retrieval tool, users need more 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 description adds substantial value beyond the 0% schema description coverage. It explains each parameter's purpose: 'symbol' (stock symbol), 'page_size' (number of rows, with max noted), 'last_time' (starting point for data), and 'output_format' (format options). This compensates well for the schema's lack of descriptions, though it doesn't specify time format for 'last_time' or clarify what 'rows' represent in the return data.
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 quote intraday price from stock market' - a specific verb ('Get') and resource ('quote intraday price'). It distinguishes from siblings like 'get_quote_history_price' by specifying 'intraday' rather than historical data. However, it doesn't explicitly contrast with other price-related tools like 'get_price_board' or 'get_quote_price_depth'.
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 intraday price data is appropriate compared to historical data from 'get_quote_history_price' or other price-related tools. There are no usage prerequisites, exclusions, or comparisons 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?
No annotations are provided, so the description carries full burden. It mentions the return type (pd.DataFrame) but lacks critical behavioral details: what constitutes a 'raw report' (e.g., financial statements, metrics, unstructured data), whether it requires authentication, rate limits, data freshness, or error handling. The description is insufficient for a mutation-free read operation with 3 parameters.
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 sized but not optimally structured. It front-loads the purpose but uses a code-like format (Args/Returns) that might be less readable. Every sentence earns its place, but the formatting could be more natural for an AI agent. It's concise but could be clearer in prose.
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 3 parameters, no annotations, and no output schema, the description is moderately complete. It covers parameters well but lacks behavioral context (e.g., what 'raw report' contains, data sources, limitations). The return type is mentioned (pd.DataFrame), but without an output schema, more detail on the structure would help. It's adequate but has clear gaps for a financial data tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by documenting all 3 parameters in the Args section with types, enums, and defaults. It adds meaning beyond the bare schema by explaining 'symbol' as 'symbol of the company', 'period' as 'period to get raw report' with options, and 'output_format' with options. This covers parameter semantics adequately despite 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 action ('Get raw report') and resource ('of a company from stock market'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from similar siblings like 'get_company_reports' or 'get_company_overview', which might offer related financial 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 for company data (e.g., get_balance_sheets, get_income_statements, get_company_overview), there's no indication of what makes 'raw report' distinct or when it should be preferred over other options.
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 lacks behavioral details. It mentions partial matching for the keyword and return type (pd.DataFrame), but doesn't cover error handling, rate limits, authentication needs, or what happens with no results. For a search tool with zero annotation coverage, 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?
The description is appropriately sized and front-loaded with the core purpose, followed by parameter and return details in a structured format. It's efficient with minimal waste, though the 'Returns: pd.DataFrame' could be integrated 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 2 parameters with 0% schema coverage and no output schema, the description does a decent job explaining parameters but lacks behavioral context and output details. It's minimally viable for a search tool but misses key operational aspects like error cases or performance hints.
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%, but the description compensates well by explaining both parameters: 'keyword' as 'partial match for fund name to search' and 'output_format' with its enum values and default. This adds meaningful context beyond the bare schema, though it could detail format implications more.
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: 'Search fund by name from stock market' specifies the verb (search), resource (fund), and scope (stock market). However, it doesn't explicitly differentiate from sibling tools like 'list_all_funds' or 'get_fund_asset_holding', 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'list_all_funds' for broader listings or other fund-related tools, leaving 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. It mentions return types (pd.DataFrame or json) but lacks behavioral details such as rate limits, authentication needs, data freshness, error handling, or whether it's read-only/destructive. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose, followed by parameter and return details. It uses bullet-like formatting for clarity, though the structure could be slightly more polished. Every sentence adds value without waste.
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, no output schema, and low schema coverage, the description is moderately complete. It covers the basic purpose, parameters, and returns, but lacks context on behavioral traits, error cases, or integration with siblings. This is adequate for a simple query tool but has clear 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the 'industry' parameter (if None, return all symbols) and listing output format options, which clarifies beyond the schema. However, it does not fully document both parameters (e.g., what 'industry' values are valid), leaving some 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 verb 'Get' and resource 'all symbols from stock market', which specifies what the tool does. It distinguishes from siblings like 'get_all_symbols' by mentioning industry filtering, though not explicitly contrasting them. However, it lacks full sibling differentiation details.
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 through the 'industry' parameter (if None, return all symbols), suggesting when to use it for filtered vs. unfiltered results. However, it does not explicitly state when to use this tool vs. alternatives like 'get_all_symbols' or 'get_all_symbols_by_group', nor provide exclusions or prerequisites.
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 return type ('pd.DataFrame') but lacks critical behavioral details like whether this is a read-only operation, potential rate limits, authentication requirements, or what happens if no funds match the criteria. The description is minimal beyond basic functionality.
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 and well-structured: a clear purpose statement followed by Args and Returns sections with bullet-like formatting. Every sentence earns its place with no wasted words.
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 and no output schema, the description provides basic functionality and parameter semantics but lacks important context like error conditions, performance characteristics, or relationship to sibling tools. It's minimally adequate but leaves gaps for a tool that presumably queries financial data.
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, the description compensates well by explaining both parameters: 'fund_type' (with enum values and None behavior) and 'output_format' (with enum values and default). This adds meaningful semantics beyond the bare schema, though it doesn't cover all possible nuances.
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 ('List') and resource ('all funds from stock market'), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'search_fund' or 'get_fund_asset_holding', which could have overlapping functionality.
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 'search_fund' or other fund-related tools. The description only explains what the tool does, not when it's appropriate or preferable.
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 mentions the return type (pd.DataFrame) but lacks critical details: whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or what happens with invalid dates/sources. The description is minimal beyond basic parameter info.
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 clear sections (Args, Returns) and uses minimal sentences. Every line adds value: the first sentence states the purpose, and subsequent lines document parameters and return type without redundancy. It could be slightly more front-loaded with behavioral 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 3 parameters with no schema descriptions and no output schema, the description does well on parameters but lacks behavioral context. It explains what the tool does and documents parameters thoroughly, but for a financial data tool with potential complexities (rate limits, data freshness, source differences), more operational guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains all three parameters: 'date' (with None default meaning today's price and format specification), 'source' (with enum values and default), and 'output_format' (with enum values and default). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 gold price from stock market' specifies the action (get) and resource (gold price). It distinguishes itself from siblings by focusing on gold prices rather than company data, funds, or other financial instruments, though it doesn't explicitly contrast with similar 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. The description doesn't mention prerequisites, context for selecting between 'SJC' and 'BTMC' sources, or when to choose different output formats. Usage is implied through parameter defaults but not explained.
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 mentions the return type ('pd.DataFrame') but lacks critical details: it doesn't specify data sources, rate limits, authentication needs, error handling, or whether it's a read-only operation. For a financial data 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter details in a bullet-like format. It's appropriately sized for a 5-parameter tool, with no redundant information. However, the 'Returns' section could be integrated more smoothly, and the formatting is slightly verbose.
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 (5 parameters, financial data) and lack of annotations or output schema, the description is moderately complete. It covers parameters well but misses behavioral context like data freshness, limitations, or error cases. Without an output schema, the 'pd.DataFrame' return hint is helpful but minimal, leaving 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant semantic value beyond the input schema, which has 0% description coverage. It explains each parameter clearly: 'symbol' as the stock symbol, date formats, default behaviors (e.g., 'None means today'), interval options with literals, and output format choices. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 quote price history of a symbol from stock market.' It specifies the verb ('get') and resource ('quote price history'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_quote_intraday_price' or 'get_price_board', 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. It doesn't mention sibling tools like 'get_quote_intraday_price' for real-time data or 'get_price_board' for current prices, nor does it specify prerequisites or exclusions. 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.
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 that it returns today's price if date is None and specifies the return type as pd.DataFrame, which is useful behavioral context. However, it doesn't mention rate limits, authentication needs, data freshness, or potential errors.
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 with clear sections (Args, Returns) and every sentence adds value. It's front-loaded with the core purpose, followed by parameter details, with zero redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description does well by explaining parameter semantics and return type. However, it could better address behavioral aspects like rate limits or data sources. The output format explanation helps compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema. While schema description coverage is 0%, the description explains both parameters thoroughly: date format (YYYY-MM-DD) and default behavior (today's price if None), and output_format options with their meanings. This fully 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 verb 'Get' and resource 'exchange rate of all currency pairs from stock market', which is specific and unambiguous. It distinguishes from siblings by focusing on exchange rates rather than company data, funds, or other financial instruments. However, it doesn't explicitly differentiate from all sibling tools by name.
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's clear this is for exchange rates, there's no mention of when to choose this over other financial data tools in the sibling list, nor any prerequisites or constraints for usage.
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

mcp-server-vietnam-stock-trading MCP server

Copy to your README.md:

[![mcp-server-vietnam-stock-trading MCP server](https://glama.ai/mcp/servers/ariesanhthu/mcp-server-vietnam-stock-trading/badges/card.svg)](https://glama.ai/mcp/servers/ariesanhthu/mcp-server-vietnam-stock-trading)

Score Badge

Copy to your README.md:

[![mcp-server-vietnam-stock-trading MCP server](https://glama.ai/mcp/servers/ariesanhthu/mcp-server-vietnam-stock-trading/badges/score.svg)](https://glama.ai/mcp/servers/ariesanhthu/mcp-server-vietnam-stock-trading)

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/ariesanhthu/mcp-server-vietnam-stock-trading'

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