VNStock MCP Server
Server Quality Checklist
Latest release: v1.0.4
- Disambiguation4/5
Most tools have distinct purposes, but some overlap exists, e.g., get_all_symbols_by_group and get_all_symbols_by_industry may return similar data for certain groups, and get_all_symbols_detailed vs list_all_companies_with_details could be confused. However, descriptions clarify differences.
Naming Consistency5/5All tool names follow a consistent 'get_' or 'list_' prefix with snake_case and descriptive nouns (e.g., get_balance_sheets, list_all_funds). No mixing of styles or ambiguous verbs.
Tool Count4/536 tools is on the higher side, but the server covers a broad domain (companies, funds, financials, prices, exchange rates, gold). Each tool addresses a specific data need, so the count is justified, though it could be streamlined slightly.
Completeness4/5The tool set covers major data categories like company fundamentals, financial statements, price history, funds, and market data. Missing features like analyst ratings or earnings calendar are minor gaps. CRUD operations are not expected for a read-only data server.
Average 3.2/5 across 36 of 36 tools scored. Lowest: 2.6/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
- Last stable release on
- 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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output_format enum and a 'toon' option described as 'optimized for AI', which adds some context. However, the return type is specified as 'pd.DataFrame' despite 'json' and 'toon' being options, creating inconsistency. No disclosure of side effects, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise at about 25 words plus docstring formatting. The Args/Returns structure is clear and front-loaded. However, the initial line is vague, and the docstring is somewhat redundant with the schema. Every sentence earns its place but lacks explanatory depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema), the description is incomplete. It fails to explain what 'group' values are valid, how to find available groups (sibling 'get_all_symbol_groups' exists but is not mentioned), or the exact behavior of output formats. The return type inconsistency further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'group: str (group name to get symbols)' and lists output_format options with a default, but adds little beyond the schema. The 'toon' optimization hint is a minor addition, but the relationship between 'group' and the returned symbols is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all symbols from stock market', aligning with the tool name 'get_all_symbols_by_group'. However, it does not distinguish from siblings like 'get_all_symbols' (which likely gets symbols without grouping) or 'get_all_symbols_by_industry'. The phrase 'by group' is not explained, leaving ambiguity about what 'group' refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, when to avoid, or how 'group' relates to other tools like 'get_all_symbol_groups'. The agent receives no help in selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'Returns: pd.DataFrame', but the input schema includes output_format options of 'json', 'dataframe', and 'toon'. This implies the return type varies, contradicting the description. No annotations are provided, so the description fails to disclose behavioral traits such as idempotency or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, using a docstring format (Args, Returns). It front-loades the purpose in the first line and only adds necessary details about parameters and return type. Could be slightly more structured by separating description from args.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks completeness for a stock market tool. It does not specify what data the overview contains (e.g., price, financials, ratios), nor does it explain how output_format affects the return value. Given the absence of an output schema and many sibling tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description attempts to compensate by listing parameters and explaining output_format's meaning ('toon is optimized for AI'). However, the 'symbol' parameter is merely named without elaboration, adding minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get company overview from stock market' which clearly identifies the action and resource. However, it does not differentiate from numerous sibling tools like get_company_reports or get_company_ratio_summary, lacking specificity on what an 'overview' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only lists arguments and return type, without explaining prerequisites, when to prefer this over other company-related tools, or if there are limitations (e.g., required exchange/symbol format).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the basic function. It fails to mention side effects (none expected), rate limits, historical depth, or that it returns a DataFrame. The output format hint ('toon' optimized for AI) is helpful but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with the main purpose front-loaded. The structured Args and Returns sections aid readability, though the parameter descriptions could be integrated more succinctly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain the returned data structure. It only states 'Returns: pd.DataFrame', which is insufficient for a complex financial report. No information is given about typical column names, date ranges, or data volume.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds minimal context: symbol is explained as 'symbol of the company', and output_format clarifies 'toon' is AI-optimized. However, period's description ('period to get balance sheets') is tautological, and all enums are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves balance sheets for a company, which distinguishes it from sibling tools like get_income_statements. However, it lacks specificity about scope (e.g., latest or historical) and could be more explicit in differentiating from similar financial statement 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_cash_flows or get_income_statements. The description omits context about prerequisites, typical use cases, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature, pagination limits, or data freshness. It only states 'Get' but does not mention any side effects, rate limits, or other important behaviors. The description adds minimal transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose followed by an arg block. The purpose is front-loaded. No unnecessary words. It earns its place, though it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and many siblings. The description does not explain the return structure (beyond 'pd.DataFrame'), event types, or how it differs from similar tools. It is incomplete for an agent to understand all nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It lists parameters with types and defaults but only explains output_format ('toon' is optimized for AI'). It does not explain symbol, page details, or the nature of events. The added value over the schema is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get company events from stock market' with a specific verb and resource. The tool is well-distinguished from siblings like get_company_news or get_company_dividends by focusing on events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_company_news or get_company_dividends. The description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It only states the basic operation and return type, with no disclosure of side effects, permissions, or potential limitations like rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The docstring format for args and returns is clear and efficient, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is somewhat complete but missing context on what the ratio summary includes, how the data is structured, and how it differs from similar tools. It meets minimum viability but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds only a note that 'toon' is optimized for AI. It restates the parameter types and enum values without explaining the meaning of the ratio summary or the format details. Some value added, but insufficient to compensate 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets a 'company ratio summary' from the stock market, with a clear verb and resource. However, it does not distinguish itself from sibling tools like 'get_finance_ratios' or 'get_company_overview', which may also return ratio-like 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/5Does 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. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the 'toon' output format as optimized for AI, which is a behavioral detail, but it fails to disclose whether the operation is read-only, any rate limits, or error handling for invalid symbols.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose. It efficiently lists parameters and return type without extraneous text. Minor improvement would be to separate parameter descriptions more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters and no output schema. Description specifies return type as pd.DataFrame but does not describe the DataFrame columns. It lacks details on edge cases or error handling, but given simplicity, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It lists parameter names and for output_format describes enum values with a note that 'toon' is optimized for AI. However, symbol lacks any description beyond the name, providing no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves company shareholders ('Get company shareholders from stock market'). It distinguishes from siblings that cover other aspects of companies (overview, officers, dividends, etc.) by focusing on shareholders. However, it does not explicitly differentiate 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/5Does 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 only states what the tool does without recommending scenarios or noting 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 exist, and the description only states that it returns a DataFrame and mentions 'toon' format. It does not discuss data freshness, pagination behavior, rate limits, or what 'intraday' precisely means. Behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with a clear header and structured Args section. It front-loads the purpose. Minor verbosity in the Args list but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and no output schema, the description should provide richer context on pagination, time range, and return column structure. It fails to do so, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning beyond the schema by noting 'max: 100000' for page_size and explaining 'toon' format. However, there is a mismatch: schema default for page_size is 100, but description says 500. This inconsistency harms reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get quote intraday price from stock market', specifying the verb and resource. However, it does not explicitly differentiate from sibling tools like get_quote_history_price or get_quote_price_depth, relying on the tool name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 when/when-not instructions, which is a gap given many sibling tools for quotes.
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. The description only notes output format options and return type (pd.DataFrame). Lacks disclosure on data volume, rate limits, or any operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and focused, but the Args/Returns formatting is slightly verbose for an AI context. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what 'detailed' means, the columns of the returned DataFrame, or any limitations (e.g., number of symbols, pagination). Incomplete for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning to the 'output_format' parameter, explaining available values and noting that 'toon' is optimized for AI. This compensates for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all symbols detailed from stock market', indicating it returns detailed information. The name differentiates from sibling 'get_all_symbols', but the description does not explicitly contrast 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_all_symbols or get_all_symbols_by_group. No conditions or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or potential side effects. It mentions return type but not consistently across output formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with a docstring style structure. It could be more streamlined by removing redundant 'Args' formatting, but it remains readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers basic parameter explanations but lacks details on return structure, behavior under different output formats, and potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides explanations for all three parameters beyond the schema definitions, including default values and the meaning of 'toon' format. Since schema coverage is 0%, this adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves income statements for a company, differentiating from sibling tools like get_balance_sheets or get_cash_flows. However, it lacks detail on what exactly is included in an income statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus related financial statement tools or other data retrieval tools. The description does not mention specific use cases 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 provided. Description does not disclose non-obvious behaviors such as rate limits, authentication requirements, or whether the operation is read-only. It mentions that 'toon' format is optimized for AI, which is a minor behavioral hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The docstring format for Args and Returns is clear, though slightly verbose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description covers the basic purpose and parameters. However, it lacks details about the return structure (e.g., fields of the DataFrame), any filtering capabilities, or pagination. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add value. It explains the default and meaning of output_format ('toon is optimized for AI') and lists the enum options. symbol is not elaborated, but overall it provides meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get company dividends from stock market' clearly states the action and resource. It distinguishes from sibling tools like get_income_statements or get_company_events, but does not explicitly differentiate 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_company_events for other financial data). No preconditions or exclusions 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 must disclose all behavioral traits. It only mentions that the tool returns a DataFrame, omitting details about read-only behavior, data source, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose and listing parameters efficiently. The docstring format is slightly informal but still clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is adequate but lacks detail about the nature of insider deals, typical data volume, or date ranges. More context would improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining the 'output_format' parameter, noting that 'toon' is optimized for AI, and indicating the return type. Although schema coverage is 0%, the docstring covers both parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'company insider deals' from the stock market. However, it does not distinguish itself from many sibling tools with similar purposes (e.g., get_company_events, get_company_news), missing specific context about what constitutes insider deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 about use cases, prerequisites, or trade-offs compared to other company information tools, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention data freshness, pagination, error handling (e.g., invalid symbol), or any side effects. The mention of output formats is helpful but insufficient for a complete behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loading the purpose in the first sentence. The docstring format (Args, Returns) adds structure but some formatting (pipes, literals) is unnecessary. Overall, nearly every element serves a function, though optional boilerplate could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return structure. It only says 'Returns: pd.DataFrame' which is minimal. For a tool with three parameters and complex output (likely multiple fields per officer), this is insufficient. The agent cannot infer data structure from this alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists parameter names and types but only adds minimal meaning: 'toon is optimized for AI' for output_format. The semantics of 'filter_by' options ('working', 'all', 'resigned') are not explained, leaving the agent to guess. Score is above baseline because it at least enumerates options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves company officers for a given stock market symbol. It uses specific verbs ('Get') and a specific resource ('company officers'). Among many sibling get_* tools, 'officers' is distinctive and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, use cases, or when to choose different filter or output format values. The description simply states what the tool does without context for 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, the description carries the full burden of behavioral disclosure. It explains the output format options and notes that 'toon' is optimized for AI, which is helpful. However, it does not disclose whether the operation is read-only, any potential latency, or side effects. Basic transparency is provided but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose line, then 'Args:' section, then 'Returns:' section. It avoids unnecessary words. The only minor issue is that the 'Args' listing repeats schema info, but it is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output is a DataFrame but does not describe the columns or content of the reports. Given the tool's complexity (simple parameters, no output schema), it leaves gaps about what data is actually returned. For instance, does it return one report or multiple? No information about the structure of the reports. Thus, it is incomplete for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning beyond the raw schema. It explains the 'output_format' enum values, highlighting 'toon' as optimized for AI, which adds value. However, for 'symbol', it only notes it is a string, adding no further context. The semantics are partially enhanced but not fully compensated for the lack of schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves company reports from the stock market. The verb 'Get' and resource 'company reports' are specific. However, it does not differentiate from sibling tools like get_company_overview or get_company_ratio_summary, leaving ambiguity about what kind of reports are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or exclusions. The agent must infer usage from context, which is insufficient.
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 provided, so description carries full burden. It mentions return type and output format but lacks details on side effects, data freshness, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise docstring format with clear sections. Purpose is front-loaded. Could be slightly more succinct but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple data retrieval tool, but lacks information about return structure beyond DataFrame type and any potential errors or limitations. With no output schema, more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains each parameter's meaning, including the 'toon' output format being AI-optimized. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves finance ratios for a company. It distinguishes from many sibling tools, but there is a similar tool 'get_company_ratio_summary' without differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_company_ratio_summary'. The description only explains parameters, not selection criteria.
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 disclose behavioral traits. It only states the action but does not mention read-only nature, data source, rate limits, or any side effects. This is insufficient for a tool fetching financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a standard Args/Returns format. It front-loads the purpose and conveys essential information with minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, no output schema), the description covers the basics. However, it lacks details on the structure of the returned data beyond 'pd.DataFrame', which could be important for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds necessary meaning. It explains that symbol is the fund symbol and defines 'toon' as an AI-optimized format. However, it does not elaborate on the differences between output formats or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get nav report of a fund', which is a specific verb-resource combination. It identifies the tool's purpose, though it does not explicitly differentiate from sibling tools like get_fund_asset_holding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention selection criteria, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It mentions the tool is a get operation (implying read-only), but does not disclose safety profile, potential side effects, authentication requirements, or rate limits. The description adds minimal behavioral context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and to the point, with clear bullet points for indicators. The first sentence is slightly awkward but not overly verbose. It effectively communicates the key feature without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description only covers the indicator parameter in detail, neglecting other important parameters like start_date, end_date, interval, drop_market_close, and output_format. There is no mention of return values or typical use cases, leaving the agent with incomplete guidance for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, high. The description adds examples for indicator parameters (e.g., 'rsi(window=21)') which are already in the schema description, providing only marginal additional value. It does not elaborate on other parameters like start_date, end_date, interval, output_format, or drop_market_close.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves quote price with indicators for a stock market symbol, and provides explicit examples of indicator formats. This distinguishes it from sibling tools like get_quote_history_price or get_quote_intraday_price which do not include indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit when-to-use or when-not-to-use context, leaving the agent to infer based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return type (DataFrame) but does not disclose behavioral traits such as rate limits, authentication requirements, idempotency, or side effects. The description implies a read operation but is not explicit about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear top-level statement followed by a structured docstring listing parameters and return type. It avoids unnecessary words, but the docstring format (e.g., 'Args:' and 'Returns:') is not standard for MCP descriptions and may be slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and return type, but lacks context on what constitutes a 'raw report' and how it differs from other report-related tools. Given the large set of sibling tools, more differentiation (e.g., 'use this for unprocessed financial data') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful explanations for each parameter beyond the schema's enum values: 'symbol' as company identifier, 'period' as quarter/year, and 'output_format' with the note that 'toon' is AI-optimized. This adds value since the schema has 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get raw report of a company from stock market', which is a specific verb and resource. It distinguishes from siblings like 'get_company_reports' by implying a more granular or unstructured report, but the exact nature of 'raw report' is not fully defined, so it falls short of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_income_statements' or 'get_balance_sheets'. The description does not mention prerequisites, common use cases, or scenarios to avoid, leaving the agent without clear decision-making support.
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 provided, so the description must fully disclose behavior. It mentions the output format 'toon' is optimized for AI, but does not reveal potential limitations such as data volume, rate limits, or pagination. For a tool returning all symbols, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using three sentences to state purpose, parameter, and return. It is front-loaded with the main action and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 optional param, no output schema), the description covers the basics: what it does, parameter meaning, and return type. However, it lacks context on performance, data size, or usage limitations, which are relevant for a tool that returns all symbols.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, output_format, is described with a brief explanation that 'toon' is optimized for AI, adding meaning beyond the enum values in the schema. Schema description coverage is 0%, so this semantic info is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all symbols from the stock market. The name and description differentiate it from sibling tools like get_all_symbols_by_group or get_all_symbols_detailed, though it does not explicitly contrast 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_all_symbols_detailed or filtered versions. The description lacks context on use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions return type (pd.DataFrame) and that 'toon' format is optimized for AI, but does not disclose side effects, rate limits, or authorization needs. It is a read operation, but no further constraints are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, front-loaded with purpose. Every sentence is informative, though slightly verbose due to Python docstring formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return type (DataFrame) but not its columns or index. It explains parameters adequately but lacks details on the returned data structure, which is important for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains both parameters: symbol as 'symbol of the fund' and output_format with enum values and note that 'toon' is optimized for AI. It adds meaning beyond schema but is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets industry holding of a fund, distinguishing it from sibling tools like get_fund_asset_holding and get_fund_top_holding. However, the term 'industry holding' could be more specific (e.g., sector allocation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose any behavioral traits such as side effects, permissions, rate limits, or that it is a read-only operation. The return type is mentioned but not the nature of the data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear front-loaded purpose and well-structured args/returns section. Every sentence adds value with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the parameter and return type, but lacks context on what 'details' means in the output. Given no output schema and many siblings, more details on the return content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the single parameter `output_format` well, including its options and the custom 'toon' format optimized for AI. This adds meaning beyond the schema, which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states that the tool lists all companies with details. However, it does not differentiate from sibling tools like `get_all_symbols` or `get_all_symbols_detailed`, which may have similar 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/5Does 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 simply states what the tool does without any context on prerequisites or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function and output format, omitting critical details such as authentication requirements, rate limits, pagination behavior, data freshness, or any side effects. The mention of 'toon' being optimized for AI is a minor behavioral hint but insufficient for comprehensive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-line purpose followed by structured parameter and return info. It is front-loaded with the main action. However, the Args/Returns formatting slightly reduces conciseness and could be streamlined (e.g., removing Python syntax) without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks completeness for a tool that returns 'all symbol groups'. It mentions a return type (pd.DataFrame) but does not specify the schema (columns, data types), potential size, or any constraints. Without an output schema, the description should provide more detail about what the dataframe contains. Additionally, no information is given about error cases or empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the single parameter 'output_format' beyond the schema. It lists the options ('json', 'dataframe', 'toon'), specifies the default ('toon'), and explains that 'toon' is optimized for AI. Since the schema has 0% description coverage, the description compensates well, though it could further clarify the structure of the 'toon' format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('all symbol groups'), and the source ('from stock market'). This distinguishes it from sibling tools like 'get_all_symbols' (which gets individual symbols) and 'get_all_symbols_by_group' (which filters symbols by group), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or contexts where this tool is preferred. Given the large set of sibling tools, this omission limits its usefulness for an AI agent deciding which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It discloses the return type (pd.DataFrame) and output format options, including that 'toon' is optimized for AI. However, it does not explain what 'trading stats' include or any behavioral traits like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three lines of purpose and args/returns. The front-loaded first line captures the essence. The Python docstring style is structured but may be slightly verbose for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain the return structure. It only states 'Returns: pd.DataFrame' without specifying columns or field names. The 'toon' format is mentioned but not fully defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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, output_format) and explains the default and meaning of 'toon' for output_format. However, it does not describe what symbol represents (e.g., a stock ticker) or what the 'json' and 'dataframe' formats output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get company trading stats from stock market', which is a specific verb-resource pair. It distinguishes from sibling tools like get_company_dividends or get_company_news by focusing on 'trading stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, context, or when to prefer other 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 present, and the description does not disclose any behavioral traits like rate limits, authentication needs, or side effects. It does mention that omitting date returns today's price, but otherwise lacks 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a clear docstring format with Args and Returns. It front-loads the main purpose. Minor improvement could be to avoid the Python docstring style for AI consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the return type (pd.DataFrame) but does not specify its structure (columns, meaning of rows). For a tool returning multiple exchange rates, knowing the output shape is important. No output schema exists to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains both parameters: date format and default behavior, and output_format options with special meaning for 'toon'. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves exchange rates for currency pairs from the stock market, but it is ambiguous whether 'all currency pairs' is realistic or includes all possible pairs. It distinguishes from sibling tools which focus on equities and funds, so purpose is mostly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as get_gold_price or other data queries. There is no discussion of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explains the return type (DataFrame) and output format options, including 'toon' for AI optimization. However, it lacks details on side effects, permissions, or data freshness, which is acceptable for a read operation but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a structured docstring-like format that is easy to parse. It avoids unnecessary details and presents essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and many sibling tools, the description is adequate but lacks some context, such as clarifying that 'asset holding' refers to full portfolio composition rather than top holdings. Additional detail could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining 'symbol' as the fund symbol and 'output_format' options with a default and purpose. Schema coverage is 0%, so this compensation is significant, though 'toon' could be defined more clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves asset holdings of a fund, using a specific verb and resource. It is distinct from sibling tools like get_fund_top_holding or get_fund_industry_holding, though it does not explicitly differentiate 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It simply states the function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return type (pd.DataFrame) and output format options, but lacks information on whether the operation is read-only, what permissions are needed, or data freshness. It does not contradict anything since no annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and structured with 'Args' and 'Returns' sections. However, it repeats the tool's purpose in the first line and then again in the docstring, which is slightly redundant. Still, it front-loads the key functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides the return type (pd.DataFrame) but does not detail the columns or how the 'toon' format differs from others. The tool's specificity within many sibling data retrieval tools is unclear, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by explaining the purpose of each parameter: symbols are a list of symbols for the price board, and output_format is an enum with 'toon' optimized for AI. This adds meaning beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('price board'), which clearly indicates the tool's function. However, it does not differentiate 'price board' from other price-related siblings like get_quote_history_price or get_quote_intraday_price, leaving ambiguity about what the price board specifically contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of scenarios, prerequisites, or comparisons to sibling tools, leaving the agent without context for 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?
No annotations are provided, so the description bears full responsibility. It mentions the return type (pd.DataFrame) and parameter options, but does not disclose any behavioral traits like data freshness, rate limits, or error conditions. The description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a docstring format with Args and Returns sections, which is clear but somewhat verbose for a simple tool. It could be more concise by integrating parameter descriptions into a shorter paragraph. The structure is logical but not optimally compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers core functionality. However, without an output schema, the Returns section is minimal ('pd.DataFrame') and lacks column details. The 'toon' output format is mentioned but not fully explained. Completeness is adequate but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining the date format, source options, and output_format meaning ('toon' is optimized for AI). It adds value beyond the schema's type/default info, though it could be more specific about the enum values and output structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get gold price from stock market', specifying the verb (Get) and resource (gold price). This distinguishes it from sibling tools, none of which mention gold price. However, it could be more precise about the market scope (e.g., which stock market).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter defaults and formats (e.g., date format YYYY-MM-DD, source defaults to 'SJC', output_format defaults to 'toon') but does not explicitly state when to use this tool versus alternatives or any prerequisites. It offers basic usage guidance but lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It lists parameters but does not disclose behavioral traits such as data freshness, rate limits, authentication requirements, or error behavior. The output format is mentioned but not fully explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with a clear first sentence and an Args block. It could be more structured (e.g., separate behaviour from parameters) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description explains parameters and returns but lacks detail on output structure, error handling, or limitations. For a historical data tool, coverage is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for most parameters (symbol, start_date, end_date, interval, output_format) with formats and defaults. However, it omits the 'drop_market_close' parameter entirely, which is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves quote price history for a stock market symbol. It uses specific verbs and resources ('Get quote price history') and distinguishes from siblings like get_quote_intraday_price which focuses on intraday 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_quote_intraday_price or get_quote_price_with_indicators. The description lists interval options but does not specify context 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?
With no annotations provided, the description carries full burden. It mentions output format options and return type but does not disclose behavioral traits like data freshness, rate limits, or safety (e.g., read-only). This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence for purpose followed by a docstring-style parameter explanation. It is front-loaded and efficiently communicates the key details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, the description covers purpose and parameter semantics adequately. However, it lacks usage guidance and behavioral context, which are important for an agent to use it correctly among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the single parameter 'output_format' with its options and default, adding that 'toon' is optimized for AI. This provides semantic meaning beyond the schema, which only lists the enum without explanation. Schema coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all ICB industries from stock market', specifying the verb 'list' and the resource 'ICB industries'. This distinguishes it from sibling tools like 'get_all_symbols_by_industry' which focus on symbols within industries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_all_symbols_by_industry' or 'list_all_companies_with_details'. The description lacks context for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions return types (pd.DataFrame or json) and output_format options, but does not explain side effects, permissions, or the exact nature of the 'toon' format beyond being optimized for AI.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a clear docstring format. However, it could be slightly more streamlined, as the args section repeats information already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 optional parameters and no output schema, the description covers purpose and returns but lacks details on data structure limits or how the output format affects the result. It also does not differentiate sufficiently from similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains both parameters: industry defaults to None (all symbols), and output_format with 'toon' optimized for AI. This adds meaningful context beyond the schema's enum list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all symbols from the stock market, with optional industry filtering. However, it does not differentiate from the sibling tool 'get_all_symbols', which likely returns all symbols without industry filtering, causing potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that setting industry to None returns all symbols, providing basic guidance. However, it does not compare to siblings like 'get_all_symbols' or 'get_all_symbols_by_group', nor does it specify when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only specifies inputs and returns. It does not disclose whether the operation is read-only, idempotent, or any potential side effects, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with sections for Args and Returns, keeping it organized. However, it includes redundant type information already present in the schema and could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, no output schema, no annotations), the description covers the essential input-output behavior. It misses potential edge cases or return format details, but is adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all three parameters beyond the schema, such as explaining that 'filter_by' and 'output_format' have specific options, and that 'toon' is optimized for AI. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 subsidiaries', with a specific source 'stock market'. It effectively distinguishes from sibling tools, which focus on other financial data 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/5Does 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 alternative tools like get_company_overview or get_company_events. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description partially covers behavior: it mentions return type (DataFrame) and output format options. However, it does not explain what 'price depth' entails (e.g., bid/ask levels) or side effects (none obvious).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, making it easy to parse. It is reasonably concise, though the Returns line is somewhat redundant given the schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters but lacks details about the returned data structure (e.g., columns of the DataFrame). For a data-retrieval tool, this omission reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains both parameters: symbol and output_format, including the default and meaning of 'toon'. This adds essential value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets quote price depth, which is a specific market data type. It distinguishes from siblings like get_quote_history_price or get_quote_intraday_price by using the term '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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_quote_price_with_indicators). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type (pd.DataFrame) and explains the 'toon' output format as optimized for AI, but does not mention error handling, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-liner and then lists the parameters in a docstring style. It is concise and well-structured, though the parameter list could be integrated more formally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema or annotations, the description provides essential information like return type and output format explanation. However, it lacks usage context, error scenarios, or data source details, making it moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: it specifies that symbol is a string, explains the default values for page_size and page, and describes the output_format enum with a note that 'toon' is optimized for AI. This goes beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get company news from stock market', which identifies the verb 'get' and the resource 'company news'. Among siblings, there is no other news-specific tool, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention limitations, preconditions, or scenarios where another tool would be more 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, and the description does not disclose behavioral traits like read-only status, rate limits, or authentication requirements. It only mentions output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief summary sentence and a structured docstring for parameters and returns. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is mostly complete but lacks details on whether the holding is current or historical, and does not specify any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaning for both parameters beyond the schema: 'symbol' is explained as 'symbol of the fund' and 'output_format' includes a note that 'toon' is optimized for AI. Schema coverage is 0%, so description adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'top holding of a fund from stock market', and it distinguishes from sibling tools like 'get_fund_asset_holding' and 'get_fund_industry_holding' by specifying 'top holding'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameters and output format but does not provide guidance on when to use this tool over alternatives, such as when to prefer 'get_fund_asset_holding' or 'get_fund_industry_holding'.
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. It lists parameters and a return type but does not disclose behavioral aspects such as error conditions, rate limits, data freshness, or side effects. The 'toon' format is mentioned as optimized for AI but not explained further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with five lines, each serving a purpose: tool purpose, parameter definitions, and return type. There is no extraneous information, and the structure is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameters are well explained, the description lacks context about output behavior (e.g., what 'toon' format returns, how results differ per output_format), error handling, or prerequisites. Given the complexity from sibling tools, some guidance on when to use this over other financial statement tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by explaining each parameter's meaning (symbol, period, output_format) and adding a helpful note about 'toon' output. All three parameters are covered with clear semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves cash flows of a company, using a specific verb ('Get') and resource ('cash flows'). It distinguishes from sibling tools like get_balance_sheets and get_income_statements by focusing on a distinct financial statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cash flow data, but does not explicitly guide when to use this tool versus alternatives (e.g., get_income_statements). No when-not-to-use or contextual advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses partial match behavior and output format options, including that 'toon' is optimized for AI. However, there is an inconsistency: the Returns section says 'pd.DataFrame' but output_format allows 'json' and 'toon', which contradicts the stated return type. No annotations exist, so the description carries full burden but fails to fully clarify 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear one-line purpose and structured Args/Returns. However, the inconsistency between the Returns claim and output_format options slightly detracts from clarity, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool, the description covers search behavior and parameters. It lacks explanation of what happens with no results, the meaning of different output formats beyond 'optimized for AI', and how results relate to sibling fund tools. No output schema exists, so more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: keyword includes 'partial match for fund name' and output_format notes the default and that 'toon' is optimized for AI. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search fund by name from stock market', which is a specific verb+resource. It distinguishes from sibling tools like 'list_all_funds' (which lists all funds without search) and other fund data retrieval tools that focus on specific aspects like holdings or NAV.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest sibling tools for related tasks. The user is left to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that 'toon' output is optimized for AI and that None fund_type returns all types. No annotations are provided, so the description carries full burden. It is transparent about the return format and optional filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. However, it includes Python type hint syntax (Literal[...]) which is slightly verbose for a tool description but not detrimental.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters, the description provides sufficient context. No output schema is needed since return type is described. Missing details like potential result size or pagination but acceptable given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning to all parameters: explains fund_type default behavior and the meaning of 'toon' in output_format. 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all funds from stock market', specifying the action and resource. It distinguishes from sibling 'search_fund' which implies a more targeted query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the fund_type parameter behavior and output_format options but does not explicitly guide when to use this tool versus alternatives like search_fund. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/MaoBui2907/vnstock-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server