YFinance MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct data types, but get_stock_info and get_multiple_quotes both provide current quote data, and get_earnings overlaps with get_financials by design. The descriptions help clarify the intended usage, making confusion unlikely in practice.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern, with get_ as the dominant prefix for data retrieval and search_stocks as a logical exception for the search action. This is a predictable and uniform naming convention.
Tool Count5/5
10 tools is well within the ideal 3-15 range for a specialized data provider, and each tool covers a distinct aspect of stock market data without unnecessary duplication.
Completeness5/5
The server covers the core financial data needs: current quotes, historical prices, dividends, splits, financials, earnings, news, recommendations, search, and batch quotes. As a read-only stock data API, it has no significant gaps.
Average 3.9/5 across 10 of 10 tools scored.
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
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value (dictionary containing dividend history), which is basic behavioral information. However, it lacks details on data coverage, limitations, or error handling, and no annotations are present to supplement.
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 brief and uses a clear Args/Returns structure. Every sentence adds value, with no extraneous information.
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 a single parameter and an output schema (not shown), the description covers the essential details. However, it omits usage differentiation and any caveats, making it less complete than ideal for guiding tool selection.
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 explains the 'symbol' parameter as 'Stock ticker symbol' with examples ('AAPL', 'GOOGL'), adding meaning beyond the bare schema type definition. This helps an agent understand the expected format.
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 'Get dividend history for a stock' clearly identifies the action and resource. It does not explicitly distinguish it from sibling tools like get_historical_data, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 such as get_historical_data or get_financials. The description only states what it does, not when it is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the accepted period and interval values and notes that a dictionary is returned, which is some behavioral context. However, it omits details like data source, whether prices are adjusted, or any error/rate-limit behavior, leaving notable 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 structured with Args and Returns sections, making it scannable. The enum lists are somewhat verbose but are justified because they substitute for missing schema descriptions. No filler or redundancy.
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 moderate complexity, the description covers parameters and return type, and an output schema exists. However, it lacks usage context, such as when to choose this over siblings or any caveats about historical data, making it minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so fully by explaining symbol with ticker examples and enumerating all valid values for period and interval. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get historical stock price data,' which is a specific verb+resource+scope. It clearly distinguishes itself from sibling tools like get_stock_info, get_dividends, and get_financials by focusing on historical price data rather than company info or corporate actions.
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 explicit when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives (e.g., using get_multiple_quotes for current prices) or exclusions, leaving the agent to infer usage solely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it returns a dictionary of news articles and leaves count as a default, but does not mention rate limits, error behavior, authentication requirements, or what 'recent' means. The description provides minimal behavioral context beyond the basic operation.
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 concise and well-structured: a one-line purpose statement, followed by a clean Args section and a Returns section. Every sentence earns its place with no padding or redundancy.
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?
The tool is relatively simple with two parameters and an output schema, which reduces the need to explain return structure. However, the description omits any usage guidance or caveats (e.g., no mention of when to use this vs. search_stocks or get_stock_info). For a standalone news retrieval tool, it is adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must add meaning. It does this effectively by explaining 'symbol' as a stock ticker with examples ('AAPL', 'GOOGL') and clarifying 'count' as the number of articles with a default value. This adds significant value beyond the schema's raw type definitions.
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 'Get recent news for a stock' using a specific verb and resource. It distinguishes itself from sibling tools like get_stock_info, get_historical_data, and get_dividends by focusing specifically on news, making its purpose unambiguous.
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?
Usage context is implied: the tool is for retrieving recent news about a stock, which is clear from the description and sibling names. However, there are no explicit instructions on when to prefer this tool over alternatives, nor any exclusion criteria 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 of behavioral disclosure. It only mentions the return type ('Dictionary containing split history') and does not disclose data format, date range, adjustment types, or error handling.
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 compact and well-structured, with clear sections for Args and Returns. It front-loads the purpose and avoids unnecessary details; every sentence earns its place.
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 one-parameter getter with an output schema present, the description covers the essential purpose and parameter. However, it omits potential caveats like split adjustment types or date range behavior, which would be useful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds crucial meaning beyond the bare schema by explaining that 'symbol' is a stock ticker and providing examples ('AAPL', 'GOOGL'). With 0% schema description coverage, this fully compensates for missing schema descriptions.
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 uses a specific verb+resource ('Get stock split history') and clearly distinguishes from sibling tools like get_dividends or get_historical_data by naming the exact data domain. It is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states the function without contextual usage, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds value by noting that the 'earnings' property is deprecated and that income statement data is used instead, which is a useful behavioral detail. However, it does not describe potential limitations, error behavior, or other important side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a valuable note, and an Args/Returns breakdown. Every sentence earns its place without unnecessary fluff.
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 one-parameter getter with an output schema available, the description provides sufficient context: what it does, what input it needs, and the general return type. It lacks usage-alternative guidance, but that is already captured in the usage dimension and does not significantly detract from 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 input schema only provides the parameter name and type, so the description's explanation that 'symbol' is a stock ticker with examples ('AAPL', 'GOOGL') adds meaningful semantic value. This compensates well for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves earnings data for a stock, using a specific verb and resource. It distinguishes itself from sibling tools like get_stock_info, get_historical_data, and get_financials by focusing specifically on earnings.
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_financials. While the purpose implies earnings-related use, it does not state explicit exclusions or scenarios where a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states that the tool returns a dictionary, without disclosing data freshness, error behavior, rate limits, or whether the operation is read-only. This is minimal transparency for an information retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the primary purpose. The Args/Returns structure is clean and every sentence adds value, with no wasted words or irrelevant details.
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 one-parameter tool with an output schema, the description covers the essential aspects: what it does and what it returns. However, it could be more explicit about the full set of 'key metrics' and how this tool differs from siblings like get_financials, so an agent might not fully understand scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'symbol' parameter (0% coverage), but the description compensates fully by explaining the parameter's meaning and providing examples ('AAPL', 'GOOGL'). This gives the agent clear guidance on what to pass.
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 verb ('Get') and the resource ('basic stock information'), with explicit examples of included data (current price, market cap, key metrics). This distinguishes it from sibling tools like get_historical_data or get_financials, which cover more specific 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 word 'basic' suggests a contrast with more specialized sibling tools, but no explicit guidance is given on when to use this tool versus alternatives. The description doesn't mention when-not-to-use or name other tools, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It states the tool 'gets' data and returns a dictionary, implying a safe read operation, but does not mention error handling, rate limits, or partial failures. The return type is also already covered by the output schema, so the description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-sentence purpose followed by structured Args and Returns sections. Every sentence serves a purpose, and the example aids understanding 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 simple one-parameter batch-quote tool with an output schema, the description covers the essential semantics. It lacks potential limit or fallback details, but the core usage is adequately specified. Given the sibling list, a brief pointer to get_stock_info for detailed single-stock info would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbols' as an array of strings with no description. The description compensates by explaining these are stock ticker symbols and gives a concrete example (['AAPL','GOOGL','MSFT']), making the parameter fully clear.
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?
Description opens with 'Get current quotes for multiple stocks at once' – a clear verb+object+scope. The 'multiple' qualifier distinguishes it from sibling tools like get_stock_info and get_historical_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 implies a batch use case ('at once') but does not explicitly state when to prefer it over single-symbol tools or provide exclusion criteria. It lacks guidance on alternatives, so usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It includes a 'Returns' line indicating a dictionary of analyst recommendations, which adds some output context. However, it does not disclose whether the operation is read-only (beyond the verb 'Get'), any authentication needs, rate limits, or data quality characteristics, leaving room for more 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 brief and well-structured: a clear one-line purpose, followed by an Args section and a Returns section. Every sentence provides necessary information without redundancy, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 an output schema, the description covers the essential elements: what it does, what input it expects, and what type of output it returns. Since the output schema exists, detailed return values are not required in the description. The simplicity of the tool makes this description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'symbol' parameter, but the tool description provides an 'Args' section explaining it as a 'Stock ticker symbol' with examples 'AAPL' and 'GOOGL'. This fully compensates for the missing schema description and clarifies the expected input format.
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 uses a specific verb 'Get' with resource 'analyst recommendations for a stock', clearly stating the tool's function. It distinguishes itself from sibling tools like get_stock_info and get_financials by focusing on recommendations.
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 does not explicitly state when to use this tool versus alternatives. The purpose is clear enough to imply usage for analyst recommendations, but there is no mention of exclusions or comparisons to sibling tools, making it implied rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the quarterly condition (True = quarterly, False = annual) and returns a dictionary. However, it does not disclose any limitations (e.g., data freshness, availability for all symbols, rate limits), which keeps this at a mid-level 3.
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 compact docstring with clear Args and Returns sections. Every sentence serves a purpose, no fluff, and it front-loads the main verb/resource. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, output schema present). The description covers the essential behavior and parameter usage, while the output schema handles return structure. No critical contextual gaps (e.g., prerequisites for a read operation) are evident, so it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates: it gives a concrete example for symbol ('AAPL') and specifies the exact behavior of the quarterly flag. This adds meaning beyond the bare schema types and defaults, making parameter semantics excellent.
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 'Get financial statements for a stock' with specific verb and resource. It is distinct from siblings like get_earnings (which focuses on earnings data) and get_historical_data (price history), so it unambiguously identifies the tool's purpose.
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 (to retrieve financial statements) and explains the quarterly vs. annual data option. It does not explicitly name alternatives or exclusions, but the purpose is self-evident among siblings, earning a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the data source (Yahoo Finance), query behavior (works best with partial tickers), a limit recommendation, and the fields returned. It does not disclose rate limits or error handling, but covers the key behavioral aspects for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose, examples, a usage note, and an Args section. There is slight redundancy between the first two sentences ('Search for stocks' vs 'searches Yahoo Finance's database'), but the overall length is appropriate and content-rich.
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?
The description is complete for a search tool: it explains parameters, usage, and return content. An output schema exists so return values are presumably defined, reducing the need for further detail. Minor gaps like error handling or case sensitivity do not significantly hinder an agent's ability to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by explaining the query parameter (company name or ticker, with examples) and limit parameter (default 10, max recommended 25). This adds meaningful guidance beyond the bare schema definitions.
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 'Search for stocks by company name or ticker symbol' with a specific verb and resource. It distinguishes from sibling tools (get_stock_info, get_historical_data, etc.) by focusing on the search/discovery use case rather than retrieving specific data for a known symbol.
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?
Provides explicit examples of effective queries and notes that complex multi-word queries may return fewer results, advising one company at a time. However, it does not directly compare with sibling tools or state when to prefer other tools over this search.
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:

[![yfinance-mcp-server MCP server](https://glama.ai/mcp/servers/barvhaim/yfinance-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/barvhaim/yfinance-mcp-server)

Score Badge

Copy to your README.md:

[![yfinance-mcp-server MCP server](https://glama.ai/mcp/servers/barvhaim/yfinance-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/barvhaim/yfinance-mcp-server)

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/barvhaim/yfinance-mcp-server'

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