MCP Yahoo Finance

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools are clearly distinct for financial data retrieval (e.g., cashflow, dividends, news), but there is notable overlap between get_current_stock_price, get_stock_price_by_date, and get_stock_price_date_range, which could cause confusion about which to use for price queries. The cmd_run tool is completely unrelated to the finance domain, creating a significant outlier.
Naming Consistency4/5
Ten of the eleven tools follow a consistent get_* verb_noun pattern, making them predictable and readable. However, cmd_run breaks this pattern with a different verb style and no clear relation to the finance theme, slightly reducing overall consistency.
Tool Count4/5
With 11 tools, the count is reasonable for a financial data server, covering key aspects like prices, financial statements, and news. It's slightly high due to redundant price tools, but still well-scoped for the domain without being overwhelming.
Completeness4/5
The toolset provides solid coverage for retrieving financial data (e.g., prices, statements, news, recommendations), but there are minor gaps such as missing company profile info or market summary tools. The unrelated cmd_run tool does not contribute to domain completeness and feels out of place.
Average 2.8/5 across 11 of 11 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it offers no information about traits such as whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what the return format looks like (e.g., structured data vs. raw text). This leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with only three words, the description is under-specified rather than efficiently structured. It fails to front-load essential information and doesn't earn its place by adding value beyond the tool name, making it ineffective despite its brevity.
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 with two parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'earning dates' entail (e.g., past vs. future dates, format), how results are returned, or any dependencies, leaving significant gaps for the agent to infer.
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 schema description coverage is 100%, with clear descriptions for both parameters ('symbol' and 'limit'), so the schema does the heavy lifting. The description adds no additional meaning beyond what's in the schema, such as explaining parameter interactions or constraints, but the baseline score of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get earning dates' is a tautology that essentially restates the tool name without adding meaningful context. It specifies the resource ('earning dates') but lacks a clear verb beyond 'get' and doesn't distinguish this tool from its siblings like 'get_dividends' or 'get_historical_stock_prices' in terms of what specific financial data it retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools (e.g., when to fetch earning dates instead of dividends or news), leaving the agent with no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states basic functionality. It doesn't disclose important behavioral traits like security implications, permission requirements, execution environment, error handling, timeout behavior, or whether commands run synchronously/asynchronously. 'Execute an arbitrary shell command' implies significant power but lacks necessary warnings or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's function. Every word earns its place with zero redundancy. It's front-loaded with the core purpose immediately apparent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and significant security implications (arbitrary shell execution), the description is dangerously incomplete. It doesn't address return format, error conditions, execution limits, or safety considerations that are critical for responsible tool 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 minimal value beyond the schema, which already has 100% coverage with a clear parameter description. The description mentions 'shell command' which provides some context about the expected content of the 'cmd' parameter, but doesn't elaborate on format, shell type, or special considerations.
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 ('Execute') and resource ('shell command'), making it immediately understandable. However, it doesn't differentiate from sibling tools, which are all financial data retrieval tools, while this is a general shell execution tool - a missed opportunity for clearer distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. Given that all sibling tools are financial data retrieval functions, there's no indication that this tool serves a completely different purpose (shell execution) or when it would be appropriate versus using the specialized financial tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves cashflow data but doesn't mention any behavioral traits such as rate limits, authentication requirements, error handling, or what format the data is returned in. This leaves significant gaps for an AI agent to understand how to use it effectively.
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 directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the cashflow data includes, how it's structured, or any potential limitations. For a tool with no structured output information, the description should provide more context to help an AI agent understand the return values and usage constraints.
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 100% description coverage, providing clear details for both parameters (symbol and freq). The description adds no additional semantic information beyond what's in the schema, such as examples or context for parameter usage. With high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('cashflow for a given stock symbol'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_income_statement' or 'get_historical_stock_prices', which might also involve financial 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for financial data (e.g., get_income_statement, get_dividends), there's no indication of when cashflow data is specifically needed or what distinguishes this tool from others in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool's function but fails to mention critical details such as data freshness (e.g., real-time vs. delayed), rate limits, error handling, or authentication needs. This is a significant gap for a tool that likely interacts with external data sources.
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 directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like data sources, reliability, or return format, which are crucial for an AI agent to use this tool effectively in a financial context with multiple sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'symbol' fully documented in the input schema as 'Stock symbol in Yahoo Finance format.' The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate but minimal value.
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 ('current stock price'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling 'get_stock_price_by_date' or 'get_stock_price_date_range', which would require mentioning the 'current' aspect more distinctly in relation to those 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_stock_price_by_date' or 'get_stock_price_date_range'. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the tool 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 full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, what data format or time range it returns, rate limits, or authentication needs. 'Get' implies reading, but specifics are lacking.
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 with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool with one parameter.
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 a simple input schema, the description is incomplete. It doesn't explain what the tool returns (e.g., dividend history, amounts, dates), potential errors, or how it differs from sibling tools, leaving gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'symbol' parameter fully. The description adds no additional meaning beyond implying it's for stocks, which is redundant with the schema's 'Stock symbol in Yahoo Finance format.' Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get dividends') and target resource ('for a given stock symbol'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'get_earning_dates' or 'get_cashflow', which would require specifying what type of financial data this returns versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_earning_dates' or 'get_cashflow', nor any context about prerequisites or limitations. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It implies a read-only operation ('Get') but doesn't specify data sources (e.g., Yahoo Finance), potential rate limits, error handling, or output format. This leaves significant gaps for an AI agent to understand how the tool behaves in practice.
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, direct sentence that efficiently conveys the core purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial data retrieval with parameters) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what the income statement includes (e.g., revenue, expenses), how data is returned, or any limitations, which could hinder an AI agent's ability to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear documentation for both parameters ('symbol' and 'freq'), including defaults and valid values. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline score of 3 for adequate coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('income statement for a given stock symbol'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its siblings like 'get_cashflow' or 'get_earning_dates' beyond mentioning 'income statement' specifically.
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_cashflow' for cash flow data or 'get_earning_dates' for earnings information. It lacks context about prerequisites, such as needing a valid stock symbol, and doesn't mention any exclusions or specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does without any details on traits like rate limits, data freshness, error handling, or output format. This is a significant gap for a tool that likely fetches external data, making it inadequate for informed usage.
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 directly states the tool's purpose without any unnecessary words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (fetching news data) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'news' entails (e.g., headlines, articles, dates), potential limitations, or how results are returned. This leaves gaps for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 100% coverage and clearly documents the 'symbol' parameter. The description implies the parameter is used to fetch news, but it doesn't provide additional context, such as examples of valid symbols or how the symbol maps to news sources. With high schema coverage, the baseline is 3.
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 ('news for a given stock symbol'), making it immediately understandable. However, it doesn't distinguish this tool from potential sibling tools that might also retrieve news-related data, such as if there were a 'get_market_news' or 'get_company_news' tool, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as whether it's for recent news, historical news, or specific sources. Given the sibling tools include various financial data tools, there's no indication of how this fits among them.
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 retrieves recommendations but does not cover critical aspects like data freshness, rate limits, authentication needs, error handling, or response format. For a tool that likely involves external data sources, this omission is significant and leaves the agent unprepared for operational nuances.
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, clear sentence: 'Get analyst recommendations for a given symbol.' It is front-loaded with the core action and resource, with no redundant or verbose language. Every word earns its place, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely involves complex financial data retrieval. It does not address behavioral traits, response structure, or usage context, which are crucial for an agent to operate effectively. While the purpose is clear, the overall context is insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'symbol' parameter fully documented in the input schema as 'Stock symbol in Yahoo Finance format.' The description adds no additional semantic context beyond this, such as examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the description does not enhance parameter understanding but also does not detract from it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get analyst recommendations for a given symbol.' It specifies the verb ('Get') and resource ('analyst recommendations') with the target ('symbol'). However, it does not distinguish this from sibling tools like 'get_news' or 'get_current_stock_price' that also retrieve financial data for symbols, leaving some ambiguity about its unique 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 prerequisites, exclusions, or comparisons to sibling tools such as 'get_news' or 'get_earning_dates', which might offer related financial insights. This lack of context could lead to misuse in scenarios where other tools are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] the stock price,' implying a read-only operation, but doesn't address critical aspects like data source (e.g., Yahoo Finance, implied by schema but not confirmed), potential rate limits, error handling (e.g., invalid symbols or dates), or output format. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality without unnecessary details. It's front-loaded with the main action and includes key constraints, making it easy to parse. There's no wasted verbiage, earning a perfect score for conciseness.
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 (a read operation with specific parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., price value, currency, or possible nulls), data freshness, or error scenarios. This leaves gaps that could hinder an agent's ability to use the tool effectively, especially without structured output information.
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 schema description coverage is 100%, with clear descriptions for both parameters ('symbol' and 'date'), including format details (e.g., 'Yahoo Finance format,' 'YYYY-MM-DD'). The description adds minimal value beyond the schema, only reiterating that parameters are for 'stock symbol' and 'specific date.' This meets the baseline score of 3, as the schema does the heavy lifting.
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 stock price for a given stock symbol on a specific date.' It specifies the verb ('Get'), resource ('stock price'), and key constraints ('on a specific date'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_current_stock_price' or 'get_historical_stock_prices', which is why it doesn't achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_current_stock_price' (for current prices) or 'get_historical_stock_prices' (for date ranges), nor does it specify prerequisites or exclusions. This leaves the agent without context for tool selection, relying solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves historical data but doesn't describe what the return format looks like (e.g., time series data, JSON structure), any rate limits, authentication needs, or error handling. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It wastes no words and is appropriately sized for a straightforward data retrieval tool, earning a high score for conciseness.
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 (retrieving historical data with three parameters) and no output schema, the description is minimally complete but lacks details on return values or behavioral traits. It covers the basic purpose but doesn't compensate for the absence of annotations or output schema, making it adequate but with clear gaps for agent usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters ('symbol', 'period', 'interval') well-documented in the input schema, including defaults and valid values. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate but not enhanced parameter information.
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 ('historical stock prices'), making it easy to understand what it does. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_current_stock_price' or 'get_stock_price_date_range', which also retrieve stock price data but with different temporal scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_current_stock_price' for real-time data or 'get_stock_price_date_range' for custom date ranges, leaving the agent to infer usage based on tool names alone without explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but does not describe traits like whether this is a read-only operation, potential rate limits, data freshness, error handling, or output format. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It is appropriately sized and avoids redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters) and no output schema, the description is minimally adequate but incomplete. It specifies what the tool does but lacks details on behavior, usage context, and output, which are crucial for an agent to invoke it correctly without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters in the input schema. The description adds no additional semantic meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating value.
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 ('stock prices'), and it specifies the scope ('for a given date range for a given stock symbol'). However, it does not explicitly distinguish it from sibling tools like 'get_historical_stock_prices' or 'get_stock_price_by_date', which likely have overlapping functionality, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_historical_stock_prices' or 'get_stock_price_by_date'. It lacks context about prerequisites, exclusions, or specific scenarios, leaving the agent to 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.

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:

[![no-use-tools MCP server](https://glama.ai/mcp/servers/marckwei/no-use-tools/badges/card.svg)](https://glama.ai/mcp/servers/marckwei/no-use-tools)

Score Badge

Copy to your README.md:

[![no-use-tools MCP server](https://glama.ai/mcp/servers/marckwei/no-use-tools/badges/score.svg)](https://glama.ai/mcp/servers/marckwei/no-use-tools)

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/marckwei/no-use-tools'

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