Yahoo Finance MCP Server

by 16Coffee

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tool set has clear thematic grouping (crypto, stock, news, etc.), but there is significant overlap within categories. For example, get_crypto_quote and get_crypto_quote_short are nearly identical, and multiple tools for stock grades (get_stock_grades, get_stock_grades_historical, get_stock_grades_summary) could confuse an agent about which to use. Descriptions help differentiate, but the boundaries are not always sharp.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., get_crypto_quote, get_historical_stock_prices), with minor deviations like lookup_identifier and search_companies. The naming is generally predictable and readable, though not perfectly uniform across all tools.
Tool Count2/5
With 34 tools, the count is excessive for a single server, making it heavy and potentially overwhelming. While Yahoo Finance is a broad domain, many tools could be consolidated (e.g., multiple crypto quote tools) or parameterized to reduce the surface area, indicating poor scoping.
Completeness5/5
The tool set comprehensively covers the Yahoo Finance domain, including stock data, crypto, news, analyst estimates, financial statements, options, and economic indicators. There are no obvious gaps; agents can perform a wide range of financial analysis tasks without dead ends.
Average 3/5 across 34 of 34 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 but offers none. It doesn't indicate whether this is a read-only operation, how results are returned (e.g., pagination, format), rate limits, authentication needs, or any side effects. This is inadequate for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('搜索加密货币相关新闻') that directly states the tool's function without any unnecessary words. It's front-loaded and appropriately sized for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter with 0% schema coverage, no annotations, no output schema, and multiple sibling tools (e.g., 'get_crypto_latest_news'), the description is severely incomplete. It fails to explain parameter usage, differentiate from siblings, or describe behavioral aspects, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameter 'symbols' is undocumented in the schema. The description adds no information about what 'symbols' represents (e.g., cryptocurrency tickers like BTC, ETH), expected format, or how it influences the search. This leaves the parameter's meaning and usage completely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '搜索加密货币相关新闻' (Search for cryptocurrency-related news) clearly states the action (search) and resource (cryptocurrency news), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_crypto_latest_news', leaving ambiguity about whether this searches historical news or provides the latest updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_crypto_latest_news' or 'get_news_sentiment'. It mentions no prerequisites, exclusions, or specific contexts, leaving the agent to infer usage 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions only the action ('获取' - get) without any information about permissions, rate limits, data freshness, pagination behavior (implied by parameters but not explained), or response format. This is inadequate for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose. It's appropriately sized and front-loaded with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It lacks essential details about parameter usage, behavioral traits, and differentiation from alternatives, making it insufficient for effective agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions '列表' (list) which hints at pagination, but doesn't explain the 'limit' and 'page' parameters, their default values, valid ranges, or how they affect the news retrieval. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取加密货币最新新闻列表' (Get the latest cryptocurrency news list) states the verb ('获取' - get) and resource ('加密货币最新新闻列表' - latest cryptocurrency news list), providing a basic purpose. However, it's vague about scope and doesn't distinguish from sibling tools like 'get_crypto_news' or 'get_stock_grade_latest_news', which could have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With multiple news-related sibling tools (get_crypto_news, get_stock_grade_latest_news, get_news_sentiment), the description offers no differentiation, prerequisites, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions '可选简略或完整模式' (optional light or full mode), which hints at behavioral differences in output format, but doesn't disclose what these modes entail, rate limits, authentication needs, error conditions, or data freshness. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that front-loads the core purpose. There's no wasted text, and it directly addresses the tool's function. However, it could be slightly more structured by separating purpose from parameter guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain return values (e.g., price data format), error handling, or historical scope (e.g., date range defaults). For a tool fetching financial data, this lacks critical context needed for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'mode' parameter with light/full options, adding some semantics beyond the schema's basic type info. However, it doesn't explain the 'symbol' parameter (e.g., format like BTC/USD), nor does it cover any date-related parameters implied by '历史' (historical). With 2 parameters and low coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get/retrieve) and resource '加密货币的历史收盘价' (historical closing prices of cryptocurrencies), which is specific. It distinguishes from siblings like get_crypto_intraday (intraday prices) and get_crypto_quote (current quotes) by focusing on historical end-of-day data. However, it doesn't explicitly mention the time range or date parameters, which would make it fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like get_crypto_intraday for intraday data or get_crypto_quote for current prices, nor does it specify prerequisites such as required symbols or date ranges. The optional mode parameter is mentioned but without context on when to choose light vs. full mode.
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. While '获取' (get) implies a read operation, the description doesn't specify what '简要行情' (brief market data) includes, whether there are rate limits, authentication requirements, error conditions, or what format the data returns. For a tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized for what it does convey, though this conciseness comes at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% parameter schema coverage, the description is inadequate. It doesn't explain what constitutes 'brief market data', how it differs from other cryptocurrency tools, what the return format looks like, or provide any parameter guidance. The description leaves too many open questions for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter 'symbol', and the tool description provides no additional parameter information. It doesn't explain what format the symbol should be in (e.g., 'BTC', 'BTC-USD', cryptocurrency ticker format), what symbols are valid, or provide examples. With low schema coverage, the description fails to compensate for the parameter documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('指定加密货币的简要行情' meaning 'brief market data for a specified cryptocurrency'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_crypto_quote' or 'get_crypto_price_eod', which likely offer different types of cryptocurrency data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple cryptocurrency-related sibling tools (get_crypto_quote, get_crypto_price_eod, get_crypto_intraday, etc.), there's no indication of what makes this 'brief' version different or when it should be preferred over other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral context. It mentions data_type options but doesn't describe what the tool returns, whether it's read-only, if there are rate limits, authentication requirements, or what happens with invalid parameters. The description doesn't contradict annotations (none exist), but it fails to provide adequate behavioral disclosure for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose first, followed by parameter details. The Chinese text is concise, and every sentence adds value. However, the parameter section could be better structured with clearer separation between different data_type requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what data is returned, format of results, error conditions, or how different data_type values affect output. For a tool with multiple data retrieval modes and no structured output documentation, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides significant parameter semantics beyond the 0% schema coverage. It explains data_type options (treasury_rates, economic_indicators, economic_calendar, market_risk_premium), clarifies that name is required when data_type is economic_indicators, and specifies date formats (YYYY-MM-DD). This compensates well for the complete lack of schema descriptions, though it doesn't fully explain all parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取宏观经济数据' (get macroeconomic data) which provides a basic purpose, but it's vague about what specific data is retrieved and how it differs from sibling tools like get_calendar_data or get_historical_stock_prices. It doesn't clearly distinguish this economic data tool from other data retrieval tools in the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for use, or comparisons to sibling tools like get_calendar_data (which might overlap with economic_calendar data_type). There's no explicit when/when-not usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions two modes ('latest' or 'search') but doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or what happens when parameters are invalid. The description adds minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear purpose statement followed by parameter documentation. The structure is front-loaded with the main function, though the parameter section could be more integrated. No wasted sentences, but the formatting as a code block with indentation is slightly awkward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description is incomplete. It covers parameters adequately but lacks crucial context about what data is returned (structure, fields), error conditions, rate limits, or authentication requirements. The absence of output schema means the description should ideally explain return values, which it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all 4 parameters: 'action_type' (latest or search), 'name' (company name in search mode), 'page' (page number, default 0), and 'limit' (return count, default 100). This adds crucial meaning beyond the bare schema, though it could provide more detail about format constraints or search behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取并购相关数据' (get M&A related data), which provides a basic purpose but is vague about what specific data is retrieved and how. It doesn't distinguish this tool from potential siblings like 'search_companies' or 'get_financial_statement' that might also provide M&A data. The verb '获取' (get) is generic rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'search_companies', 'get_financial_statement'), there's no indication of whether this is the primary M&A data source or how it differs from other data retrieval tools. Usage is implied through parameter documentation but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions pagination (page, limit) and that some event types require a symbol, but lacks critical behavioral details: whether this is a read-only operation, rate limits, authentication needs, error handling, or what the output format looks like. The description is minimal and doesn't compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by parameter details. It's relatively concise but could be more structured; the parameter explanations are listed without clear headings or separation, and some sentences are redundant (e.g., repeating '部分类型需要股票代码' could be integrated better). Overall, it's adequate but not optimally organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It covers parameters well but misses behavioral context, output details, and usage guidelines. For a tool fetching financial calendar data, this leaves gaps in understanding how to interpret results or handle errors, making it insufficient for full agent comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant value by explaining each parameter: event_type with its enum-like options, symbol as optional for some types, and page/limit with defaults. This goes beyond the bare schema, though it doesn't detail format constraints (e.g., symbol format) or interdependencies (e.g., which event_types require symbol).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取分红、收益、IPO、拆股等日历信息' (Get calendar information for dividends, earnings, IPOs, splits, etc.). It specifies the resource (calendar data) and types of events, though it doesn't explicitly differentiate from sibling tools like get_economic_data or get_stock_actions, which might have overlapping financial data domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lists event types but doesn't explain context, prerequisites, or exclusions. For example, it doesn't clarify if this is for historical or future events, or how it differs from tools like get_stock_actions that might handle similar data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fetches intraday prices and supports specific intervals, but doesn't mention critical behaviors like whether this is a read-only operation, rate limits, authentication requirements, data freshness, error handling, or response format. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence in Chinese that directly states the tool's function and parameter constraints. It's front-loaded with the core purpose and wastes no words. Every part of the sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (data fetching with time intervals), no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't explain what the tool returns (price data structure, timestamps, fields), error conditions, or behavioral constraints. For a financial data tool, users need to understand the output format and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some semantic context: it explains that 'interval' accepts '1min, 5min and 1hour' values, which the schema doesn't specify (0% coverage). However, it doesn't clarify the 'symbol' parameter format (e.g., ticker conventions like BTC/USD). With 2 parameters and 0% schema description coverage, the description partially compensates but doesn't fully document both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取加密货币的分时价格' (get intraday cryptocurrency prices) with specific time intervals. It uses a specific verb ('获取' - get) and resource ('加密货币的分时价格' - cryptocurrency intraday prices). However, it doesn't explicitly distinguish this from sibling tools like 'get_crypto_price_eod' (end-of-day prices) or 'get_crypto_quote' (current quotes), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_crypto_price_eod' for end-of-day prices or 'get_crypto_quote' for current quotes, nor does it specify use cases or exclusions. The only implied context is needing intraday data, but this is minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it retrieves '完整行情' (complete market data), which implies a read-only operation, but doesn't specify what 'complete' includes, whether there are rate limits, authentication requirements, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple tool with one parameter and is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and 0% schema description coverage, the description is insufficiently complete. It doesn't explain what '完整行情' includes, how the data is structured, or any operational constraints, leaving the agent with inadequate context for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions '指定加密货币' (specified cryptocurrency), which aligns with the 'symbol' parameter in the schema. However, with 0% schema description coverage, the description doesn't add meaningful details about parameter format, examples, or constraints beyond what's implied. It compensates minimally for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('指定加密货币的完整行情' meaning 'complete market data for specified cryptocurrency'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'get_crypto_quote_short' or 'get_crypto_price_eod', which would require more specific differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_crypto_quote_short' or 'get_crypto_price_eod'. There's no mention of prerequisites, context, or comparison with sibling tools, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool retrieves news, it doesn't describe what kind of news (financial, general, sentiment-labeled), how many items are returned, whether there's pagination, time recency, data sources, rate limits, or authentication requirements. For a news retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences, but the structure could be improved. The purpose statement is clear, but the parameter explanation is separated into a '参数说明' section rather than integrated naturally. While not wasteful, it lacks the polished flow of front-loading all critical information in a single coherent paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of news retrieval (which involves multiple behavioral aspects like filtering, formatting, and limitations) with no annotations and no output schema, the description is incomplete. It doesn't explain what the news list contains (headlines, summaries, dates, sources, sentiment scores despite the tool name), how results are ordered, or what format they're returned in. For a tool with 'sentiment' in its name but no output schema, this is particularly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful parameter semantics beyond the schema. The input schema has 0% description coverage (just 'ticker' with title 'Ticker'), but the description explains that 'ticker' is a stock code with an example ('AAPL'). This adds crucial context about format and expected values, though it doesn't specify allowed ticker formats or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取指定股票的相关新闻列表' (Get news list for specified stock). It uses a specific verb ('获取' - get) and resource ('新闻列表' - news list) with a clear scope ('指定股票' - specified stock). However, it doesn't distinguish from sibling tools like 'get_stock_grade_latest_news' or 'get_crypto_news', which appear to serve similar functions for different asset classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple news-related sibling tools (get_crypto_news, get_stock_grade_latest_news, get_stock_grade_news), there's no indication of how this tool differs in scope, recency, or content. It doesn't mention prerequisites, exclusions, or comparative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, format of returned dates, or whether it's a real-time or cached query. For a financial data tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a parameter explanation. There's no wasted text, though the structure could be slightly improved by integrating the parameter note more seamlessly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial data query), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what the output looks like (e.g., list of dates, format), error conditions, or dependencies. For a tool that likely returns structured date data, this leaves too much unspecified for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the ticker parameter as a stock code with an example ('AAPL'), which clarifies the expected format. However, it doesn't cover other potential aspects like validation rules or supported exchanges. With one parameter partially documented, this meets the baseline for minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取指定股票可用的期权到期日' (Get available option expiration dates for a specified stock). It specifies the verb (get/获取) and resource (option expiration dates/期权到期日), and distinguishes it from siblings like get_option_chain (which likely provides full option chains). However, it doesn't explicitly differentiate from all siblings, just implies a specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or compare it to sibling tools like get_option_chain. The only implied context is needing option expiration dates for a stock, but no explicit usage rules are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves historical data, implying it's a read-only operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, data freshness, error handling, or output format (e.g., JSON structure, date ranges). For a data retrieval tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences, but the structure is not fully front-loaded. The first sentence states the purpose clearly, but the second sentence is a parameter explanation that might be better integrated or omitted if schema coverage were higher. It's concise but could be more streamlined for an agent's quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (historical data retrieval), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what the output includes (e.g., dividend amounts, split ratios, dates), how far back history goes, or any limitations. For a tool with one parameter but rich expected output, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for the single parameter 'ticker' by explaining it's a stock code with an example ('AAPL'), which clarifies format and intent beyond the schema's basic string type. However, it doesn't cover constraints like valid ticker formats or error cases, preventing a score of 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取股票的分红与拆股历史' (Get stock dividend and split history), which is a specific verb+resource combination. It distinguishes from siblings like get_historical_stock_prices (price data) or get_financial_statement (financial reports), but doesn't explicitly differentiate from tools like get_stock_grades_historical (historical grades) or get_stock_info (general info), keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires a valid ticker), exclusions (e.g., not for crypto or indices), or compare to siblings like get_stock_info (which might include some action data). Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '获取' (get) implies a read operation, the description doesn't mention important behavioral aspects like: whether this requires authentication, rate limits, what format the ratings come in, whether it's real-time or delayed data, or what happens if the ticker is invalid. For a tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: the purpose statement followed by parameter documentation. There's no wasted text, and the information is front-loaded with the main purpose first. The bilingual nature (Chinese purpose, Chinese parameter docs) is efficient for its target audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and only 0% schema description coverage, the description is incomplete. It doesn't explain what the tool returns (ratings format, structure, possible values), doesn't mention error conditions, and doesn't provide enough behavioral context for safe usage. Given the complexity of financial data tools and the lack of structured documentation, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides parameter documentation in Chinese: 'ticker: str 股票代码，例如 "AAPL"' (ticker: str stock code, for example "AAPL"). With 0% schema description coverage, this adds meaningful semantic information about what the parameter represents and provides an example. However, it doesn't specify format constraints (e.g., exchange prefixes, case sensitivity) or validation rules beyond the basic example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取分析师最新评级' (Get latest analyst ratings). It specifies the verb ('获取' - get) and resource ('分析师最新评级' - latest analyst ratings), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_ratings' or 'get_stock_grades_historical', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to ratings/grades (get_ratings, get_stock_grades_historical, get_stock_grades_summary), there's no indication of what distinguishes this 'latest' ratings tool from those other options. The description simply states what it does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the purpose without adding any behavioral traits such as whether it's read-only, requires authentication, has rate limits, or describes the return format. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the purpose in the first sentence, followed by a parameter explanation. It avoids unnecessary verbosity, but the structure could be slightly improved by integrating the parameter details more seamlessly rather than as a separate section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It lacks information on behavioral traits, return values, and usage context. For a tool with these gaps, the description should provide more comprehensive guidance to be adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a parameter section that explains 'ticker' as a stock code with an example 'AAPL', adding meaning beyond the input schema which has 0% description coverage. However, it only covers the single parameter without detailing format constraints or other nuances, so it partially compensates but doesn't fully address the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: '获取分析师评级汇总' (Get analyst rating summary). It specifies the verb '获取' (get) and resource '分析师评级汇总' (analyst rating summary), making it understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_ratings' or 'get_stock_grades', which appear related, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_ratings' or 'get_stock_grades', nor does it specify any context, prerequisites, or exclusions for usage. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves data ('获取'), implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, data freshness, error conditions, or what the output contains. For a financial data tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by parameter details. There's no wasted text, and the bilingual presentation (Chinese purpose, Chinese parameter labels with English hints) is efficient. However, the structure could be slightly improved by integrating the parameter explanations more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial valuation tool), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the returned data includes (e.g., valuation metrics, assumptions), how to interpret results, or any limitations. For a tool with 2 parameters and significant domain specificity, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema. The schema has 0% description coverage (titles only: 'Symbol' and 'Valuation Type'), while the description explains that 'valuation_type' can be 'dcf' or 'levered' and 'symbol' is a stock code. This compensates well for the low schema coverage, though it doesn't detail format constraints (e.g., symbol conventions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取 DCF 或杠杆 DCF 估值数据' (Get DCF or levered DCF valuation data). It specifies the verb ('获取' - get) and resource ('估值数据' - valuation data), and distinguishes between DCF and levered DCF types. However, it doesn't explicitly differentiate from sibling tools like get_financial_statement or get_analyst_estimates, which might also provide valuation-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for choosing between DCF and levered DCF, or how it differs from other financial data tools in the sibling list (e.g., get_analyst_estimates). Usage is implied by the parameter descriptions but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '搜索' (search) implies a read operation, the description doesn't address important behavioral aspects like whether this requires authentication, rate limits, what happens with no results, whether results are paginated, or what format the results take. For a search tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose first, followed by parameter explanations. The Chinese text is efficient with no wasted words, though the parameter section could be slightly more integrated with the main description rather than appearing as a separate block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what constitutes a 'company' in this context, what fields are returned, how results are ranked, or what happens with ambiguous queries. The parameter explanations help, but key behavioral and output information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides meaningful parameter information that compensates well. It explains that 'query' is the search keyword, 'limit' controls result count with a default of 10, and 'exchange' is an optional exchange code. This covers all three parameters with useful semantic context beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '根据关键字搜索公司信息' (search for company information based on keywords), which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_directory_list' or 'lookup_identifier', which might also retrieve company information through different mechanisms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available for retrieving financial data (e.g., 'get_directory_list', 'lookup_identifier', various crypto tools), there's no indication of when this keyword-based company search is appropriate versus other data retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('获取'), implying a read-only operation, but doesn't clarify permissions, rate limits, data freshness, or potential side effects. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured parameter list. Each sentence earns its place by providing essential information without redundancy. It could be slightly more concise by integrating defaults into the parameter explanations more smoothly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and parameters well, but lacks behavioral context (e.g., pagination details, error handling, data format) and doesn't explain return values. For a data retrieval tool, this is adequate but leaves room for improvement in operational transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains all four parameters: 'symbol' as stock code (e.g., 'AAPL'), 'period' as annual or quarter with default 'annual', 'page' as page number with default 0, and 'limit' as return count with default 10. This compensates well for the schema's lack of descriptions, though it doesn't detail constraints like valid symbol formats or period enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取分析师的财务预估数据' (Get analyst financial estimate data). It specifies the verb '获取' (get) and the resource '分析师的财务预估数据' (analyst financial estimate data), which is specific enough to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_ratings' or 'get_price_target_info', which might also relate to analyst data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_ratings' or 'get_price_target_info', nor does it specify any prerequisites, contexts, or exclusions for usage. The only implied usage is for retrieving analyst estimates, but without comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('get') but lacks details on permissions, rate limits, response format, or whether it's read-only. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned list includes (e.g., symbols, names, metadata), how it's formatted, or any behavioral traits, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add param info, but this is acceptable given the lack of parameters, aligning with the baseline for 0 params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get') and resource ('交易所上市的加密货币列表' meaning 'list of exchange-listed cryptocurrencies'), making the purpose unambiguous. It doesn't explicitly distinguish from siblings like 'get_crypto_quote' or 'get_crypto_price_eod', but the focus on 'list' rather than specific quotes or prices provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, nor does it reference sibling tools like 'get_crypto_quote' for detailed data or 'get_all_crypto_quotes' for broader quotes, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('获取市场或公司目录列表') without mentioning permissions, rate limits, response format, or other behavioral traits. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the purpose stated first followed by parameter details. It avoids unnecessary fluff, though the parameter explanation could be slightly more integrated. Overall, it's efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and no output schema, the description is minimally adequate. It covers the purpose and parameter semantics well, but lacks behavioral context and usage guidelines, leaving gaps in completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% coverage. It explains the single parameter 'list_type' with a detailed list of possible values (e.g., stock, financial_statement_symbol), clarifying its semantics. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取市场或公司目录列表' (Get market or company directory list). It specifies the verb '获取' (get) and resource '目录列表' (directory list), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'get_crypto_list' or 'search_companies', which also retrieve lists, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_crypto_list' for cryptocurrency data or 'search_companies' for company searches, nor does it specify contexts or exclusions. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination (page, limit parameters) which is useful, but doesn't describe response format, error conditions, rate limits, authentication requirements, or what happens when symbol is omitted for certain info_types. For a financial data tool with 4 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value, though the Chinese/English mixing could be slightly cleaner. The information is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers parameter meanings well but lacks information about return values, error handling, and behavioral constraints. Given the financial data context and sibling tools offering similar data, more guidance on tool selection would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential parameter semantics: it explains info_type options (summary, consensus, news, latest_news), indicates symbol is required for news/summary/consensus, and provides defaults for page and limit. This compensates well for the schema's lack of descriptions, though it doesn't fully explain all parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取分析师目标价相关信息' (get analyst price target information) with specific info_type options (summary, consensus, news, latest_news). It distinguishes this from siblings like get_analyst_estimates or get_ratings by focusing specifically on price targets rather than broader analyst data. However, it doesn't explicitly contrast with these siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions the info_type parameter options, it doesn't explain when to choose summary vs consensus vs news, or how this tool differs from other financial data tools in the sibling list. There's no mention of prerequisites, limitations, or comparison to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what data is retrieved but doesn't mention rate limits, authentication needs, data freshness, error handling, or pagination behavior beyond basic parameter defaults. For a data retrieval tool with no annotation coverage, this leaves significant gaps in understanding how it behaves operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by a structured parameter section. Every sentence adds value, with no redundant information. It could be slightly more concise by integrating parameter details more seamlessly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and parameters well but lacks behavioral context (e.g., rate limits, data sources) and output details. For a data retrieval tool, this is adequate but leaves room for improvement in explaining what the returned data looks like or any usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all parameters: 'info_type' specifies 'single' or 'all', 'symbol' is required for single queries, 'page' handles pagination with default 0, and 'limit' controls return count with default 1000. This clearly explains what each parameter does, though it could benefit from examples or constraints (e.g., valid symbol formats).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取流通股数据或全部公司流通股列表' (Get circulating share data or a list of all company circulating shares). It specifies the verb (get/retrieve) and resource (circulating shares), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_stock_info' or 'get_stock_actions', which might also provide share-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for choosing between 'single' or 'all' info types, or how it relates to sibling tools like 'get_stock_info' or 'get_stock_grades'. Usage is implied through parameter descriptions but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination behavior (page/limit parameters with defaults) which is useful, but doesn't describe what 'rating news' entails, whether it's real-time or historical, what format the news items come in, or any rate limits/authentication requirements. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured. The purpose statement is front-loaded, followed by organized parameter explanations. Every sentence earns its place by providing essential information. It could be slightly more concise by integrating the parameter explanations more seamlessly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers parameters well but doesn't explain what 'rating news' means, what the return format looks like, or how this differs from similar tools. For a tool with no output schema and no annotations, more context about the return value would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics despite 0% schema description coverage. It explains all 3 parameters with clear examples and constraints: ticker as stock code with 'AAPL' example, page as page number with default 0, and limit as items per page with max 100 and default 1. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取指定股票的评级新闻' (Get rating news for specified stock), which is a specific verb+resource combination. It distinguishes from siblings like get_stock_grades (which likely provides ratings data rather than news) and get_stock_grade_latest_news (which might provide only latest rather than paginated results). However, it doesn't explicitly differentiate from all similar siblings in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate versus get_ratings, get_stock_grades, get_stock_grade_latest_news, or other news-related tools. There are no explicit when/when-not instructions or named alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions a limit parameter with a maximum of 1000 and default of 100, which adds some behavioral context. However, it doesn't disclose other important traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the return format looks like (e.g., JSON structure, pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the purpose statement first, followed by parameter details. Every sentence earns its place by providing essential information without redundancy. The bilingual nature (Chinese purpose, Chinese parameter labels with English examples) is efficient for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and parameter semantics but lacks details on behavioral traits and return values. For a tool with 2 parameters and historical data retrieval, it's minimally adequate but leaves gaps in understanding the full operation and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains that 'ticker' is a stock symbol like 'AAPL' and 'limit' specifies the number of records to return with a maximum of 1000 and default of 100. This compensates well for the lack of schema descriptions, though it doesn't cover all possible nuances (e.g., ticker format constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取分析师评级历史记录' (get analyst rating historical records), which is a specific verb+resource combination. It distinguishes from siblings like 'get_stock_grades' (which might be current ratings) and 'get_ratings' (which could be different rating types), though it doesn't explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'get_stock_grades' or 'get_ratings', nor does it specify prerequisites or contexts for usage beyond the basic parameter requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information ('获取'), implying a read-only operation, but doesn't specify any behavioral traits such as rate limits, authentication requirements, data freshness, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the purpose stated first followed by parameter details. It uses two sentences efficiently, avoiding unnecessary information. However, the structure could be slightly improved by integrating the parameter explanation more seamlessly, but it remains clear and concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameter semantics but lacks behavioral transparency and usage guidelines. Without an output schema, it doesn't explain return values, which is a gap. The description meets basic needs but leaves room for improvement in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema. The schema has 0% description coverage (only a title 'Ticker' and type 'string'), but the description provides a parameter explanation: '股票代码，例如 "AAPL"' (stock code, e.g., 'AAPL'), clarifying the expected format and giving an example. This compensates well for the low schema coverage, though it doesn't detail constraints like valid ticker formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取公司概况及关键财务指标' (Get company overview and key financial indicators). It specifies the verb '获取' (get) and the resource '公司概况及关键财务指标' (company overview and key financial indicators). However, it doesn't explicitly differentiate from siblings like 'get_financial_statement' or 'get_ratings', which reduces the score from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., get_financial_statement, get_ratings, get_analyst_estimates), there is no indication of what distinguishes this tool's scope or when it should be preferred over others. The only implied context is from the purpose statement, but no explicit usage rules are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, how data is sourced (e.g., real-time vs. delayed), rate limits, or output format, which are critical for a financial data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's function without any fluff. It's front-loaded and every word contributes to understanding the purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data tools and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'top gainers' means (e.g., by percentage or absolute value), how many stocks are returned, data freshness, or error handling, leaving significant gaps for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose, which aligns with the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('今日涨幅最大的股票列表' meaning 'today's top gaining stock list'), providing a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'get_top_losers' beyond the obvious opposite direction, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, frequency limits, or compare it to similar tools like 'get_stock_grades' or 'get_historical_stock_prices' for performance analysis, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs a query/lookup, which implies a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or what the return format might be (e.g., structured data, list of results). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by a parameter section. There's no wasted text, and it's structured for clarity. However, it could be slightly more concise by integrating parameter details more seamlessly, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context: 2 parameters with 0% schema coverage, no annotations, no output schema, and moderate complexity (a lookup tool), the description is minimally adequate. It covers the purpose and parameters well, but lacks behavioral details and usage guidelines. Without output schema, it doesn't explain return values, which is a gap, but the parameter coverage helps balance it to a baseline level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema. The schema has 0% description coverage (no descriptions in properties), but the description provides clear explanations: 'identifier_type' with optional values (symbol, name, cik, cusip, isin, exchange_variant) and 'query' as the corresponding content. This compensates well for the low schema coverage, though it doesn't detail format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '按标识类型查询股票代码、CIK、CUSIP 或 ISIN' (Query stock symbols, CIK, CUSIP, or ISIN by identifier type). It specifies the verb '查询' (query/lookup) and the resources (stock symbols, CIK, CUSIP, ISIN). However, it doesn't explicitly differentiate from sibling tools like 'search_companies' or 'get_stock_info', which might offer similar functionality, so it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_companies' or 'get_stock_info', nor does it specify any prerequisites, exclusions, or contextual cues for usage. The only implied usage is based on the purpose, but no explicit guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't specify whether this is a real-time or cached query, rate limits, authentication needs, or what 'all' entails (e.g., all available cryptocurrencies or a predefined set). The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's function without any fluff or redundancy. It's front-loaded and appropriately sized for a no-parameter tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0 parameters, no annotations, and no output schema, the description is minimally adequate but lacks depth. It explains what the tool does but doesn't address behavioral aspects like data freshness, scope, or error handling. Given the complexity of fetching 'all' crypto quotes, more context would be helpful, but it meets the basic threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description correctly omits parameter information, focusing on the tool's purpose. A baseline of 4 is appropriate as it doesn't mislead or add unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('全部加密货币的批量行情' meaning 'batch quotes for all cryptocurrencies'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_crypto_quote' or 'get_crypto_price_eod', which might offer more targeted or different types of crypto data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone. This is a significant gap given multiple crypto-related siblings exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves data (implying read-only), but doesn't disclose behavioral traits like authentication needs, rate limits, data freshness, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences, but the structure is slightly awkward with a mix of Chinese and English. The first sentence states the purpose, and the second explains parameters, but it could be more front-loaded and polished for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description provides basic purpose and parameter semantics. However, it lacks details on return values, error handling, or behavioral context, making it incomplete for a tool that likely returns complex executive data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: info_type specifies the data type (executives, compensation, benchmark) and symbol indicates when it's required. This adds crucial meaning beyond the bare schema, though it doesn't detail parameter formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves executive information or compensation data for companies, specifying the resource (executives/compensation/benchmark) and action (获取/retrieve). It distinguishes from siblings like get_financial_statement or get_stock_info by focusing on executive data, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the info_type parameter options (executives, compensation, benchmark) and notes symbol is required for two types. However, it lacks explicit guidance on when to use this tool versus alternatives like get_stock_info or get_analyst_estimates, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, data freshness, or output format. For a tool with zero annotation coverage, this is a significant gap in transparency about how it behaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without any fluff. It's front-loaded with the core function and appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It explains what the tool does but lacks details on output format, data sources, or error handling. For a tool that likely returns a list of stocks, more context on the return structure would be helpful, but it's adequate for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied for zero-parameter tools, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取今日跌幅最大的股票列表' (Get today's list of stocks with the largest declines). It specifies the verb ('获取' - get) and resource ('股票列表' - stock list) with a clear scope ('今日跌幅最大的' - today's largest declines). However, it doesn't explicitly distinguish from its sibling 'get_top_gainers', which is a closely related tool for top gainers rather than losers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_top_gainers' for contrast, nor does it specify prerequisites, frequency, or contextual cues for invocation. The user must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what data is retrieved but doesn't disclose behavioral traits like rate limits, authentication requirements, data freshness, error conditions, or response format. The description is purely functional without operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two clear sections: a purpose statement and parameter documentation. Every sentence earns its place. Minor improvement could be front-loading the parameter section more clearly, but overall it's efficient without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides good parameter coverage but lacks behavioral and output context. For a data retrieval tool with 2 parameters, it's minimally adequate but misses important operational details like response format, error handling, and data scope limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides complete parameter documentation: ticker format with example ('AAPL') and financial_type with all 6 possible enum values explicitly listed. This adds substantial meaning beyond the bare schema, effectively documenting both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取公司财报' (get company financial statements) with specific resource types (income statement, balance sheet, cash flow statement) and periodicity (annual/quarterly). It distinguishes from siblings by focusing on financial statements rather than quotes, news, or other data. However, it doesn't explicitly differentiate from potential similar tools not in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or comparison with sibling tools like get_analyst_estimates or get_dcf_valuation that might provide related financial data. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions pagination parameters, it doesn't describe important behavioral aspects like whether this is a read-only operation, what authentication might be required, rate limits, what format the news is returned in, or whether there are any side effects. For a news retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by well-organized parameter documentation. Every sentence serves a purpose, and there's no wasted text. The parameter explanations are concise yet complete. The only minor improvement would be better separation between the purpose statement and parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description provides adequate but incomplete coverage. It fully documents the parameters, which is good, but lacks important context about the tool's behavior, return format, and differentiation from similar tools. For a news retrieval tool, users need to know what kind of data to expect in return, which isn't addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing complete parameter documentation in Chinese. It explains both parameters (page and limit), their data types, default values, and constraints (limit maximum of 1000). This adds substantial value beyond what the bare schema provides, making the parameter usage clear despite the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取最新评级新闻' (get latest rating news), which is a specific verb+resource combination. It distinguishes itself from siblings like 'get_ratings' or 'get_stock_grades' by focusing specifically on news about ratings. However, it doesn't explicitly differentiate from 'get_stock_grade_news' which appears to be a very similar sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_ratings', 'get_stock_grades', and the very similar 'get_stock_grade_news', there's no indication of what makes this tool distinct or when it should be preferred over other rating-related tools. The description only explains what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns specific price data (date, open, high, low, close, volume) and mentions constraints like '分钟级数据最多可追溯60天' (minute-level data can trace back up to 60 days), which is useful behavioral context. However, it doesn't cover other important aspects like rate limits, authentication needs, error conditions, or data freshness, leaving gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured. It starts with the core purpose, then lists parameters with clear explanations in a bullet-like format. Every sentence adds value, with no redundant information. It could be slightly more front-loaded by emphasizing key constraints earlier, but overall it's efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and parameters well, but lacks output details (beyond listing returned fields), error handling, or examples. For a data retrieval tool with sibling alternatives, more context on data format or usage scenarios would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains all three parameters in detail: 'ticker' as stock code with an example ('AAPL'), 'period' with supported values and default, and 'interval' with supported values, constraints ('分钟级数据最多可追溯60天'), and default. This fully compensates for the lack of schema descriptions and provides clear semantics for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取指定股票的历史价格，返回日期、开盘价、最高价、最低价、收盘价和成交量' (Get historical stock prices for a specified stock, returning date, open, high, low, close prices and volume). It specifies the verb ('获取' - get), resource ('股票的历史价格' - historical stock prices), and output format. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_stock_info' or 'get_stock_actions', which might also provide stock-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'get_stock_info', 'get_stock_actions', 'get_financial_statement'), there's no indication of how this tool differs in context or when it should be preferred. The parameter explanations imply usage for historical price retrieval but don't address tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data (implied read-only) and describes two modes (snapshot/historical), but doesn't disclose important behavioral traits like rate limits, authentication requirements, data freshness, error conditions, or what format the ratings data returns. For a data retrieval tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured. The first sentence states the purpose clearly, followed by a parameter section with bullet-point explanations. Each sentence earns its place by adding value. It could be slightly more front-loaded with a clearer distinction from sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers parameters well but lacks behavioral context and output information. For a data retrieval tool without annotations or output schema, the description should ideally explain what the ratings data looks like and any important constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the schema. With 0% schema description coverage, the description fully compensates by explaining all three parameters: symbol (stock code with example), rating_type (snapshot/historical with default), and limit (return count with default). It adds meaningful context that the schema alone doesn't provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取股票评级数据' (get stock rating data). It specifies the resource (stock ratings) and the action (get/retrieve). While it doesn't explicitly differentiate from all siblings, it distinguishes from tools like get_stock_grades or get_stock_grades_historical by focusing specifically on 'ratings' rather than 'grades'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context by mentioning the choice between snapshot or historical data, which suggests when to use each rating_type. However, it doesn't explicitly state when to use this tool versus alternatives like get_stock_grades or get_stock_grades_historical, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does but lacks behavioral details such as rate limits, authentication requirements, error conditions, or what the output format looks like. The description does not disclose any operational constraints beyond basic parameter usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence, followed by parameter details. Every sentence earns its place by providing essential information without redundancy. Minor deduction for slightly verbose parameter formatting in Chinese.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well on parameters but lacks completeness for a data retrieval tool: it doesn't describe the return structure, pagination, or error handling. It's adequate for basic use but has clear gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics: it explains each parameter's purpose, gives examples (e.g., 'AAPL'), specifies formats ('YYYY-MM-DD'), and enumerates valid values ('calls' or 'puts'). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('获取期权链数据' - get option chain data) and resources (stock ticker, expiration date, option type). It distinguishes itself from siblings like 'get_option_expiration_dates' by focusing on retrieving the actual chain data rather than just expiration dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the parameter explanations (e.g., '期权类型：'calls' 或 'puts''), but does not explicitly state when to use this tool versus alternatives like 'get_stock_info' or 'get_historical_stock_prices'. No guidance on prerequisites or exclusions is provided.
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:

[![finance-mcp MCP server](https://glama.ai/mcp/servers/16Coffee/finance-mcp/badges/card.svg)](https://glama.ai/mcp/servers/16Coffee/finance-mcp)

Score Badge

Copy to your README.md:

[![finance-mcp MCP server](https://glama.ai/mcp/servers/16Coffee/finance-mcp/badges/score.svg)](https://glama.ai/mcp/servers/16Coffee/finance-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/16Coffee/finance-mcp'

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