finance-tools-mcp是一个模型上下文协议 (MCP) 服务器，旨在为大型语言模型 (LLM) 提供全面的财务洞察和分析能力。它由investor-agent修改而来，可与各种数据源和分析库集成，提供一套用于详细财务研究和分析的工具。
Related MCP server: Trading MCP Server
服务器通过 MCP 公开各种工具，允许连接的客户端（如 LLM）访问特定的财务数据并执行分析：
股票数据工具：
get_ticker_data ：提供给定股票代码的综合报告，包括概述、新闻、关键指标、表现、日期、分析师建议以及升级/降级。
get_options ：检索股票代码未平仓合约最高的期权数据，并提供日期范围、执行价格和期权类型（看涨/看跌）的过滤选项。
get_price_history ：获取指定时期的历史价格数据摘要，包括 OHLCV 样本、技术指标、风险指标和其他定量分析。
get_financial_statements ：获取股票行情的财务报表（收入、余额、现金流），可按季度或年度获取。
get_institutional_holders ：列出股票代码的主要机构和共同基金持有人。
get_earnings_history ：提供股票盈利历史，包括估值和意外情况。
get_insider_trades ：检索股票代码的近期内幕交易活动。
get_ticker_news_tool ：获取特定股票代码的最新雅虎财经新闻。
恐惧与贪婪指数工具：
get_current_fng_tool ：获取当前 CNN 恐惧与贪婪指数得分和评级。
get_historical_fng_tool ：检索指定天数的历史 CNN 恐惧与贪婪指数数据。
analyze_fng_trend ：分析特定时期内 CNN 恐惧与贪婪指数的趋势。
计算工具：
calculate ：使用 Python 的数学语法和 NumPy 计算数学表达式。
宏观数据工具：
get_current_time ：提供当前时间。
get_fred_series ：检索特定 FRED 系列 ID 的数据。
search_fred_series ：按关键字搜索热门的 FRED 系列。
cnbc_news_feed ：从 CNBC、BBC 和 SCMP 获取最新的世界新闻。
该服务器利用yfinance检索股票的历史价格数据（OHLCV，即开盘价、最高价、最低价、收盘价、成交量）。这些原始数据经过大量处理和分析，以提供有价值的见解，并特别针对法学硕士 (LLM) 的使用进行了优化。
时间序列数据处理的关键方面包括：
**全面分析：**使用ta-lib-python等库分析数据，计算各种技术指标。此外，自定义函数可计算基本统计数据、风险指标，识别常见图表模式，并计算斐波那契回撤位。
**结构化摘要：**此分析的结果被编译成易于 LLM 解析和理解的结构化摘要格式（ generate_time_series_digest_for_LLM ），其中包括统计数据、摘要、技术指标、风险指标、模式、斐波那契水平和数据样本等部分。
**LLM 的智能采样：**为了向 LLM 提供具有代表性的历史数据视图，且不至于使上下文窗口过载，我们采用了“智能采样”策略 ( get_latest_data_sample )。此方法以不同的分辨率对数据进行采样：
**高分辨率：**每天都包含最新的数据点。
**中等分辨率：**每周对中间数据点进行采样。
**低分辨率：**每月对旧数据点进行采样。这种混合方法可确保 LLM 接收有关近期价格走势的详细信息，同时仍掌握长期趋势的背景信息，所有这些都在可控的数据点数量范围内。
这种对时间序列数据的优化处理和呈现使 LLM 能够快速掌握关键趋势、指标和模式，从而促进更明智的财务分析。
Python： 3.10 或更高版本
软件包管理器： uv
首先，如果尚未安装uv ，请安装它：
curl -LsSf https://astral.sh/uv/install.sh | sh然后，您可以使用uvx运行finance-tools-mcp MCP 服务器：
uvx finance-tools-mcp如果您想使用自己的 FRED API 密钥，可以将其设置为环境变量：
FRED_API_KEY=YOUR_API_KEY uvx finance-tools-mcp您还可以使用服务器发送事件（SSE）传输运行服务器：
uvx finance-tools-mcp --transport sse或者使用 FRED API 密钥和 SSE 传输：
FRED_API_KEY=YOUR_API_KEY uvx finance-tools-mcp --transport sse要将finance-tools-mcp与 MCP 客户端（例如 Claude Desktop）集成，请将以下配置添加到claude_desktop_config.json中：
{
"mcpServers": {
"investor": {
"command": "path/to/uvx/command/uvx",
"args": ["finance-tools-mcp"],
}
}
}您可以利用 MCP 检查器来调试服务器：
npx @modelcontextprotocol/inspector uvx finance-tools-mcp或者
npx @modelcontextprotocol/inspector uv --directory ./ run finance-tools-mcp对于日志监控，请检查以下目录：
macOS： ~/Library/Logs/Claude/mcp*.log
Windows： %APPDATA%\Claude\logs\mcp*.log
对于本地开发和测试：
按照调试部分中的说明使用 MCP 检查器。
使用 Claude Desktop 进行以下配置测试：
{
"mcpServers": {
"investor": {
"command": "path/to/uv/command/uv",
"args": ["--directory", "path/to/finance-tools-mcp", "run", "finance-tools-mcp"],
}
}
}此 MCP 服务器采用 MIT 许可证。详情请参阅许可证文件。
[ ] 添加股票支撑位和阻力位
[x] 为股票添加斐波那契回撤位
[ ] 添加股票移动平均汇合水平
[ ] 添加选项模型进行预测
[ ] 使用财务表和其他功能添加预测模型
fintel.com
投资网站
雅虎
fred.stlouisfed.org
CNN、CNBC 和 Reddit
Analyze trends in CNN Fear & Greed Index over specified days.
Parameters:
days (int): Number of days to analyze (limited by available data).
Returns:
str: A string containing the analysis results, including latest value,
average value, trend direction, and number of data points analyzed.
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the analysis output format (latest value, average, trend direction, data points) which is valuable, but doesn't mention rate limits, data freshness, or error conditions. It adequately describes what the tool produces but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter and return sections. Every sentence adds value: the first defines scope, the parameter explanation clarifies constraints, and the return details specify output content without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides good coverage: it explains the tool's purpose, parameter meaning, and return format. The main gap is lack of explicit usage guidance versus siblings, but otherwise it's reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage (parameter 'days' has no description in schema), but the description compensates by explaining the parameter's purpose ('Number of days to analyze') and constraint ('limited by available data'). This adds meaningful context beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Analyze trends') and resource ('CNN Fear & Greed Index') with temporal scope ('over specified days'). It distinguishes from siblings like 'get_historical_fng_tool' by emphasizing trend analysis rather than raw data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for trend analysis of the Fear & Greed Index, but provides no explicit guidance on when to use this versus alternatives like 'get_historical_fng_tool' or 'get_overall_sentiment_tool'. The context is clear but lacks comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the result of a mathematical expression. Support python math syntax and numpy. > calculate("2 * 3 + 4") {'result': 10} > calculate("sin(pi/2)") {'result': 1.0} > calculate("sqrt(16)") {'result': 4.0} > calculate("np.mean([1, 2, 3])") {'result': 2.0}
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes |
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 performs calculations but does not cover important traits like error handling (e.g., for invalid expressions), performance considerations (e.g., complexity or rate limits), or security aspects (e.g., safe evaluation). The examples imply it returns a dictionary with a 'result' key, but this is not explicitly stated in the description text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by illustrative examples. Each example earns its place by demonstrating usage, but the formatting with code blocks and quotes could be slightly more streamlined for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is partially complete. It covers the purpose and parameter semantics well but lacks usage guidelines and behavioral details. For a computation tool, more context on limitations or error cases would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds significant meaning by explaining that the 'expression' parameter accepts mathematical expressions using Python math syntax and numpy, with examples illustrating valid inputs. This goes beyond the schema's basic string type, though it could be more explicit about constraints or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('calculate') and resource ('result of a mathematical expression'), distinguishing it from sibling tools that focus on financial data, news, or time retrieval. It explicitly mentions support for Python math syntax and numpy, which further clarifies its mathematical computation role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparisons with sibling tools, leaving the agent to infer usage based on the purpose alone. This lack of explicit context reduces its effectiveness in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest breaking world news from CNBC, BBC, and SCMP. Useful to have an overview for the day. Include the Fed rate prediction from Fed watch and key macro indicators.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what content is included (news from specific sources, Fed predictions, macro indicators) but doesn't cover critical aspects like rate limits, freshness of data, authentication needs, or potential costs. For a tool fetching real-time news without annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in the first sentence. The second sentence adds context about daily overviews and specific content inclusions. There's no wasted text, though it could be slightly more structured (e.g., bullet points for content types).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fetching real-time news from multiple sources) and lack of annotations or output schema, the description is moderately complete. It specifies sources and content types but omits details on output format, data freshness, or error handling. For a news tool with no structured output documentation, this leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately focuses on the tool's function without redundant information. A baseline of 4 is justified as it efficiently handles the parameter-less case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the latest breaking world news from CNBC, BBC, and SCMP' with specific sources and content types (Fed rate prediction, key macro indicators). It distinguishes itself from sibling tools like 'get_ticker_news_tool' by focusing on general world news rather than ticker-specific news, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: 'Useful to have an overview for the day' suggests it's for daily news summaries. However, it doesn't specify when to use this versus other news-related tools (e.g., 'get_ticker_news_tool' or 'social_media_feed'), nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current time in ISO 8601 format.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (ISO 8601) which is useful behavioral context, but does not mention timezone behavior, latency, or error conditions. It adequately describes the core behavior but lacks depth on operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the tool's purpose and output format without any wasted words. It is perfectly front-loaded and appropriately sized for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no annotations and no output schema, the description provides sufficient context about what the tool does and its output format. However, it could be more complete by mentioning timezone handling or potential limitations, though not strictly necessary for basic functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the output format. This meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('current time'), with precise output format ('ISO 8601 format'). It distinguishes from all sibling tools which are finance-related, making its purpose unambiguous and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (to obtain current time in a specific format), but does not explicitly mention when not to use it or name alternatives. Given the distinct nature of this tool compared to finance-focused siblings, the context is clear but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get earnings history with estimates and surprises.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
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 data is retrieved but doesn't disclose behavioral traits like whether this is a read-only operation, requires authentication, has rate limits, returns historical vs real-time data, or error conditions. 'Get' implies read-only, but this isn't explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 6 words, front-loading the core purpose with zero wasted words. Every element ('earnings history', 'estimates', 'surprises') contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 minimal schema coverage, the description is incomplete. It doesn't explain what 'estimates and surprises' means in practice, return format, time range covered, or data sources. For a financial data tool with behavioral unknowns, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the schema provides. With 0% schema description coverage and 1 parameter, the baseline is 3 since the schema documents the ticker parameter minimally. The description doesn't compensate by explaining ticker format, valid values, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'earnings history', specifying it includes 'estimates and surprises'. This distinguishes it from siblings like get_financial_statements or get_price_history by focusing on earnings data. However, it doesn't explicitly differentiate from all possible earnings-related tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare with siblings like get_financial_statements which might overlap. The agent must infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get financial statements. Types: income, balance, cash. Frequency: quarterly, annual.
| Name | Required | Description | Default |
|---|---|---|---|
| frequency | No | quarterly | |
| statement_type | No | income | |
| ticker | Yes |
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 what types of statements can be retrieved and frequency options, but doesn't describe critical behavioral aspects: whether this requires authentication, rate limits, what format the data returns (e.g., raw numbers, structured JSON), whether it's a read-only operation, or any potential errors. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first two words. The additional details about types and frequency are efficiently presented in a single sentence. There's no wasted text, though it could benefit from slightly more structure (e.g., bullet points) for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data retrieval (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., structured financial data, raw text), any authentication requirements, error handling, or how it differs from sibling tools. For a tool with no structured support, the description should provide more context to guide effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some semantic context beyond the schema: it explicitly lists the statement types (income, balance, cash) and frequency options (quarterly, annual), which correspond to the enum values in the schema. However, with 0% schema description coverage, it doesn't explain the 'ticker' parameter or provide additional details like format examples or constraints. The description partially compensates but doesn't fully address the coverage gap for all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get financial statements' with specific types listed (income, balance, cash), which is a clear verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_earnings_history' or 'get_ticker_data', which might also provide financial data, leaving some ambiguity about when to use this specific tool versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_earnings_history' or 'get_ticker_data'. It lists frequency options (quarterly, annual) but doesn't explain when to choose one over the other or any prerequisites for usage. There's no mention of context or exclusions, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a FRED series by its ID. However the data is not always the latest, so use with caution!!!
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes |
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 a critical limitation ('data is not always the latest'), which is valuable context beyond the basic operation. However, it lacks details on other behavioral traits such as error handling, response format, rate limits, or authentication needs, leaving significant gaps for a tool that fetches data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the core purpose, and the second adds a crucial caution. It is front-loaded with the main action and appropriately sized for the tool's complexity, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. While it covers the basic purpose and a key limitation, it misses essential context such as return values, error conditions, and operational details. For a data retrieval tool with these gaps, more information 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic information. The description adds meaning by specifying that the parameter is a 'FRED series ID', which clarifies the purpose of 'series_id'. However, it doesn't elaborate on format, examples, or constraints, leaving the parameter only partially documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'FRED series by its ID', which is specific and unambiguous. It distinguishes from sibling 'search_fred_series' by focusing on retrieval by ID rather than search. However, it doesn't explicitly contrast with other data-fetching siblings like 'get_price_history' or 'get_ticker_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a caution about data freshness ('not always the latest, so use with caution'), which implies usage context for when timeliness matters. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'search_fred_series' or other data retrieval tools, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical CNN Fear & Greed Index data for a specified number of days.
Parameters:
days (int): Number of days of historical data to retrieve (limited by the API).
Returns:
str: Historical Fear & Greed Index values for the specified period.
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes |
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 that the number of days is 'limited by the API,' which hints at potential constraints, but doesn't specify rate limits, authentication needs, error conditions, or what happens if the limit is exceeded. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by parameter and return sections. Every sentence adds value, and there's no redundant information. It could be slightly more front-loaded by emphasizing key constraints earlier, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is adequate but has gaps. It explains the parameter and return type, but lacks details on behavioral aspects like error handling or API limits. Without annotations or output schema, it should ideally provide more context on what the returned data looks like (e.g., format, structure).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'days' by explaining it represents 'Number of days of historical data to retrieve' and noting it's 'limited by the API.' Since schema description coverage is 0% (the schema only provides type and title), this compensates well by clarifying the parameter's purpose and constraints, though it doesn't specify exact limits or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get historical CNN Fear & Greed Index data for a specified number of days.' It specifies both the verb ('Get') and resource ('historical CNN Fear & Greed Index data'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_current_time' or 'get_price_history' that might also retrieve time-series data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'analyze_fng_trend' (which might process this data) or 'get_current_time' (which might provide different temporal data), nor does it specify prerequisites or exclusions. The only implicit usage hint is the parameter description mentioning API limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent insider trading activity.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
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 ('Get recent insider trading activity') without any details on traits like data freshness, rate limits, authentication needs, error handling, or what 'recent' means. This is inadequate for a tool with potential complexity in financial data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence: 'Get recent insider trading activity.' It is front-loaded and wastes no words, making it easy to parse quickly. Every word contributes directly to the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial data retrieval), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter details, or output expectations, leaving the agent with insufficient information to use the tool effectively in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('ticker') with 0% description coverage, meaning the schema provides no semantic details. The description does not mention the parameter at all, failing to add any meaning beyond the schema. For a tool with undocumented parameters, this is a significant gap, as it doesn't explain what 'ticker' represents or how it should be formatted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent insider trading activity' clearly states the verb ('Get') and resource ('insider trading activity'), making the purpose understandable. However, it lacks specificity about scope (e.g., time frame, data source) and doesn't distinguish from siblings like 'get_ticker_data' or 'get_financial_statements', which might also provide financial data. It's not tautological but remains somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings such as 'get_ticker_data' or 'get_financial_statements' that might overlap in financial data retrieval, there's no indication of when this specific tool is appropriate, nor any prerequisites or exclusions mentioned. This leaves the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive market sentiment indicators including:
- CNN Fear & Greed Index (score and rating)
- Market RSI (Relative Strength Index)
- VIX (Volatility Index)
Returns:
str: Formatted string containing all three indicators with their current values
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses what data is returned (three specific indicators) and the return format (formatted string), which is helpful. However, it doesn't mention behavioral aspects like data freshness, rate limits, authentication requirements, or error conditions that would be important for a financial data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a bulleted list of indicators and a returns section. Every sentence earns its place by providing essential information without redundancy. The formatting with bullet points enhances readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, and no output schema, the description provides adequate coverage of what the tool does and what it returns. However, it lacks important context about data sources, update frequency, and potential limitations that would help an agent use it effectively in financial analysis scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool returns, which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comprehensive market sentiment indicators' and lists three specific indicators (CNN Fear & Greed Index, Market RSI, VIX). It distinguishes from siblings like 'get_historical_fng_tool' by focusing on current comprehensive sentiment rather than historical data. However, it doesn't explicitly contrast with all relevant siblings like 'analyze_fng_trend'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this comprehensive sentiment view is preferable over individual indicators from siblings like 'get_historical_fng_tool' or 'analyze_fng_trend', nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical price data digest for specified period. There're two kinds of response mode: 1. The period mode. It will generate a digest for LLM consumption. Usually get at least 3 months, 6 months or more. The response includes OCHLCV samples, Technical Indicators (by ta-lib) , Risk Metrics, and other quantitative analysis. 2. The start_date and end_date mode. Once the start_date (yyyy-mm-dd) and end_date (yyyy-mm-dd) are specified, it will generate a raw OCHLCV data in the slot. And no digest will be generated in this mode. Useful for checking the price history of a specific short date range.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | ||
| period | No | 6mo | |
| start_date | No | ||
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: two distinct response modes with different outputs (digest vs raw data), what each mode includes (OCHLCV samples, technical indicators, risk metrics for digest mode), and format expectations (yyyy-mm-dd for date mode). However, it doesn't mention rate limits, authentication needs, error conditions, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but could be more front-loaded. The first sentence states the purpose, but the detailed mode explanations follow. Some sentences could be tightened (e.g., 'There're two kinds of response mode:' could be 'Two response modes:'). Overall efficient but not perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description provides good context about modes and outputs but leaves gaps. It explains what the tool returns in each mode but doesn't describe the structure of the 'digest' or 'raw OCHLCV data.' Given the complexity of financial data analysis, more detail about output formats would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining the semantic relationship between parameters: two distinct modes (period mode vs start_date/end_date mode), format requirements for dates (yyyy-mm-dd), and practical guidance (get at least 3 months for period mode). It clarifies that ticker is required and how period/enum values relate to the 'period mode'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'gets historical price data digest for specified period' with specific mention of response modes. It distinguishes from siblings like get_ticker_data or get_earnings_history by focusing specifically on price history with digest/raw data outputs. However, it doesn't explicitly contrast with all possible siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each mode: 'period mode' for LLM consumption with digest (recommending 3+ months) and 'start_date/end_date mode' for raw data of specific short date ranges. It doesn't explicitly mention when NOT to use this tool versus alternatives like get_ticker_data or analyze_fng_trend.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive report for ticker: overview, news, metrics, sector / industry valuation, performance, dates, analyst recommendations, and upgrades/downgrades.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
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 describes what data is retrieved but lacks critical behavioral details such as whether this is a read-only operation, rate limits, authentication needs, data freshness, or error handling. The description is functional but misses key operational context needed for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get comprehensive report for ticker') and lists key components without unnecessary words. Every part earns its place by clarifying scope, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fetching diverse financial data) and lack of annotations or output schema, the description is moderately complete. It outlines the report components but doesn't cover behavioral aspects like data sources, update frequency, or response format. For a tool with no structured metadata, it provides a functional overview but leaves gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 1 parameter and 0% schema description coverage, the description compensates well by specifying that the parameter is a 'ticker' and implying it's for fetching a comprehensive report. It adds meaning beyond the bare schema, though it doesn't detail format constraints (e.g., ticker symbol conventions) or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('comprehensive report for ticker'), listing detailed components like overview, news, metrics, etc. It distinguishes from obvious siblings like get_ticker_news_tool (which focuses only on news) and get_price_history (which focuses only on price data), but could be more explicit about differentiation from other data-fetching tools like get_financial_statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for use, or compare with siblings like get_financial_statements or get_earnings_history, leaving the agent to infer usage based on the broad scope implied by 'comprehensive report'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For getting yahoo financial news of a ticker. Useful for getting latest news, especially for doing deep research.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the source (Yahoo) and general use case (latest news, deep research), but fails to disclose critical behavioral traits such as rate limits, authentication needs, error handling, or the format/scope of returned news (e.g., number of articles, time range). This leaves significant gaps for an AI agent to understand operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly state the tool's function and use case, with no redundant information. It is front-loaded by starting with the core purpose. However, it could be slightly more structured by separating functional details from usage advice for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (news retrieval with potential variability in output) and the lack of annotations and output schema, the description is incomplete. It does not explain what the return values include (e.g., headlines, dates, links), how results are formatted, or any limitations (e.g., news recency, source reliability). This inadequately supports an AI agent in invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'ticker' with 0% schema description coverage, meaning the schema provides no details about this parameter. The description adds some meaning by specifying it's for 'a ticker' in the context of Yahoo financial news, but does not elaborate on format (e.g., stock symbol conventions), validation, or examples. This partially compensates for the low coverage but remains minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'getting yahoo financial news of a ticker' and 'getting latest news', which specifies the verb (get), resource (Yahoo financial news), and scope (for a ticker). However, it does not explicitly distinguish this from sibling tools like 'cnbc_news_feed' or 'social_media_feed', which might also provide news but from different sources or with different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it's 'useful for getting latest news, especially for doing deep research', suggesting it's best for recent news and in-depth analysis. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'cnbc_news_feed' or 'social_media_feed', nor does it specify any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top 25 institutional holders and their changes for a given stock ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns real-time or historical data, or details the format of 'changes' (e.g., percentage, absolute values). For a tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get top 25 institutional holders and their changes for a given stock ticker.' It is front-loaded with the core action and resource, with no unnecessary words or redundancy. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial data retrieval), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'changes' entail, the data source, update frequency, or error handling. For a tool that likely returns structured financial data, more context is needed to use it effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('ticker') with 0% description coverage, meaning the schema provides no semantic details. The description adds value by clarifying that 'ticker' refers to a 'stock ticker', which is useful context. However, it doesn't elaborate on format constraints (e.g., uppercase, validation) or examples, so it only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get top 25 institutional holders and their changes for a given stock ticker.' It specifies the verb ('Get'), resource ('top 25 institutional holders and their changes'), and scope ('for a given stock ticker'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_ticker_data' or 'get_financial_statements', which might also provide holder-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools such as 'get_ticker_data' or 'get_financial_statements' that might offer similar or overlapping functionality. The user is left to infer usage based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for the most popular FRED series by keyword. Useful for finding key data by name. Like GDP, CPI, etc. However the data is not always the latest.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that results show 'most popular' series and data may not be latest, adding useful behavioral context. However, it misses critical details like response format, pagination, error handling, or authentication needs, which are essential for a search tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Each sentence adds value: first states the action, second clarifies utility, third gives examples, fourth notes a limitation. There is no wasted text, though it could be more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers basic purpose and a limitation but lacks details on parameters, return values, error cases, or integration with siblings. For a search tool with minimal structured data, 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.
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 'keyword' which aligns with the 'query' parameter, but provides no additional semantics (e.g., format, examples beyond GDP/CPI, or search scope). With one undocumented parameter and minimal elaboration, it fails to adequately supplement the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for FRED series by keyword, specifying the resource (FRED series) and verb (search). It distinguishes from siblings like 'get_fred_series' by focusing on keyword-based search rather than direct retrieval. However, it doesn't explicitly contrast with all siblings, keeping it at 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'useful for finding key data by name' and provides examples like GDP and CPI. It hints at limitations ('data is not always the latest'), but lacks explicit when-to-use vs. alternatives (e.g., 'get_fred_series' for specific series) or clear exclusions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes and summarizes option data for a given ticker.
This function retrieves option indicators and Greeks for the specified ticker,
generates a digest summarizing key metrics, and formats a table of key option
data including last trade date, strike, option type, open interest, volume,
and implied volatility.
Args:
ticker: Stock ticker symbol.| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
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 retrieving option indicators and Greeks, generating a digest, and formatting a table, but lacks details on permissions, rate limits, data sources, or error handling. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 and details following. It avoids redundancy, but the Args section repeats parameter info that could be integrated more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is moderately complete. It covers the purpose and parameter semantics but lacks behavioral details and output information, which is a gap for a tool performing analysis and summarization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by specifying that 'ticker' is a 'Stock ticker symbol,' which clarifies its semantics. With 0% schema description coverage and only 1 parameter, this compensates well, though it doesn't detail format constraints (e.g., uppercase).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyzes and summarizes option data for a given ticker.' It specifies the verb (analyzes, summarizes) and resource (option data), and distinguishes it from siblings like get_ticker_data or get_price_history by focusing on options. However, it doesn't explicitly differentiate from all possible option-related tools that might be added later.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or compare it to sibling tools like get_ticker_data for general data or calculate for other calculations. Usage is implied by the purpose 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_fng_trendcalculatecnbc_news_feedget_current_timeget_earnings_historyget_financial_statementsget_fred_seriesget_historical_fng_toolget_insider_tradesget_overall_sentiment_toolget_price_historyget_ticker_dataget_ticker_news_toolget_top25_holderssearch_fred_seriessocial_media_feedsuper_option_toolScored across 17 tools
Most tools have distinct purposes, but there is some overlap that could cause confusion. For example, get_historical_fng_tool and analyze_fng_trend both deal with Fear & Greed Index data, and get_ticker_data includes news while get_ticker_news_tool is specifically for news. However, descriptions help clarify differences, such as analyze_fng_trend focusing on trend analysis versus get_historical_fng_tool for raw data retrieval.
The naming follows a consistent snake_case pattern with a verb_noun structure for most tools, like get_price_history and search_fred_series. There are minor deviations, such as calculate being a single verb and cnbc_news_feed using a noun_verb_noun pattern, but overall, the naming is predictable and readable.
With 17 tools, the count is slightly high but reasonable for a finance domain that covers diverse areas like market data, news, sentiment, and analysis. It provides comprehensive coverage without being overwhelmingly large, though it borders on the heavy side for typical MCP server scopes.
The tool set offers broad coverage for financial analysis, including data retrieval (e.g., price history, financial statements), sentiment indicators, news feeds, and specialized tools like options analysis. Minor gaps exist, such as no explicit tools for portfolio management or trading actions, but agents can work around this with the available tools for core financial workflows.
The Octagon MCP server provides specialized AI-powered financial research and analysis by integrating with the Octagon Market Intelligence API. It enables users to analyze public market data (SEC filings, earnings transcripts, financial metrics, and stock data for 8000+ companies), private market data (3M+ companies, 500k+ funding rounds, 2M+ M&A/IPO transactions), and conduct deep research including web scraping capabilities. The server also features autonomous research agents that search hundreds of sources and return fully cited reports in approximately one minute.
7-factor stock scoring MCP server. US/HK/CN, 74 stocks. Free + Premium (USDC/Base). x402 ready.
Production MCP server for US equity and options intelligence: real-time IV radar, Monte Carlo simulation, options pressure, strategy backtesting, AI prediction, pre-trade risk analysis, and automated stock research reports.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
social_media_feedA
Get most discussed stocks and investments opinions from reddit. Useful to know what investors are talking about. keywords is optional. Set keywords to match the specific topic you are interested in, by 'OR' operator, e.g. ['tsla', 'tesla'], ['tesla', 'spacex'], ['AAPL', 'apple', 'tim cook', 'cook'] No keywords will return the most discussed stocks and investments.
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's function and parameter usage but lacks critical behavioral details such as rate limits, authentication requirements, data freshness, pagination, or error handling. For a tool fetching real-time social media data, these omissions are significant gaps that could impact agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. Each sentence adds value: the first defines the tool, the second gives usage context, and the remaining sentences detail parameter behavior with examples. There's no redundant information, though the structure could be slightly improved by separating the examples into a bullet list for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (fetching social media data), no annotations, and no output schema, the description is partially complete. It covers the purpose and parameter usage well but lacks details on output format, data recency, limitations, or error cases. This leaves gaps that could hinder an agent's ability to use the tool effectively in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It effectively explains the 'keywords' parameter: it's optional, used to match specific topics via 'OR' operator, and provides concrete examples like ['tsla', 'tesla']. This adds meaningful semantics beyond the bare schema, clarifying how the parameter influences the tool's behavior and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get most discussed stocks and investments opinions from reddit.' It specifies the verb ('Get'), resource ('stocks and investments opinions'), and source ('from reddit'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'cnbc_news_feed' or 'get_ticker_news_tool', which might also provide financial content from different sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: 'Useful to know what investors are talking about.' It explains the optional parameter behavior: 'No keywords will return the most discussed stocks and investments.' However, it doesn't explicitly state when NOT to use this tool or mention alternatives among the sibling tools, such as using 'cnbc_news_feed' for professional news instead of social media opinions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.