Finance Tools MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
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.
Naming Consistency4/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 3.2/5 across 17 of 17 tools scored. Lowest: 2.4/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.
This repository includes a glama.json configuration file.
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?
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.
Conciseness5/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial 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.
Parameters2/5
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.
Purpose3/5
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.
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 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.
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 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.
Conciseness5/5
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.
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 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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource '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.
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, 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.
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 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.
Conciseness4/5
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.
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 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.
Parameters3/5
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.
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 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.
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_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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify 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.
Conciseness5/5
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.
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 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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get top 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.
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, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It 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.
Conciseness4/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema 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.
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 '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.
Purpose4/5
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.
Usage Guidelines3/5
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.
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 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.
Conciseness4/5
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.
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 (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.
Parameters4/5
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.
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 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.
Usage Guidelines2/5
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.
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 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.
Conciseness4/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter '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.
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 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.
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 '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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the 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.
Conciseness4/5
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.
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 (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.
Parameters3/5
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.
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: '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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it'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.
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 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.
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 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is moderately complete. It covers 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.
Parameters4/5
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.
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: '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.
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_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.
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 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.
Conciseness5/5
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.
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. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource '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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core 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.
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 (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.
Parameters4/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for 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.
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 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or 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.
Behavior3/5
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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a bulleted list of 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.
Completeness3/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the 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.
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 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.
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 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the 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.
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 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.
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 (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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It 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.
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 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness3/5
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.
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 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.
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 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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/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 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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the 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.
Conciseness5/5
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.
Completeness4/5
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.
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. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('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.
Usage Guidelines4/5
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.

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-tools-mcp MCP server](https://glama.ai/mcp/servers/VoxLink-org/finance-tools-mcp/badges/card.svg)](https://glama.ai/mcp/servers/VoxLink-org/finance-tools-mcp)

Score Badge

Copy to your README.md:

[![finance-tools-mcp MCP server](https://glama.ai/mcp/servers/VoxLink-org/finance-tools-mcp/badges/score.svg)](https://glama.ai/mcp/servers/VoxLink-org/finance-tools-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/VoxLink-org/finance-tools-mcp'

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