mcp-yeoman

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes focused on different financial data types (sentiment, ticker info, news, top lists by sector), but there is some overlap between get_ticker_news and search_news which could cause confusion about when to use each. The other tools are clearly differentiated by their target data or function.
Naming Consistency5/5
All tools follow a consistent snake_case naming pattern with clear verb_noun structure (e.g., analyze_sentiment, get_ticker_info, search_news). The naming is predictable and readable throughout the set, with no mixing of conventions or styles.
Tool Count5/5
With 10 tools, this server is well-scoped for financial data analysis, covering sentiment, ticker information, news, and various top lists by sector. Each tool serves a specific purpose without redundancy, and the count is typical for a domain-focused server.
Completeness4/5
The toolset provides comprehensive coverage for financial data retrieval and analysis, including sentiment, ticker details, news, and sector-based rankings. A minor gap is the lack of tools for historical price data or portfolio management, but core workflows for research and monitoring are well-supported.
Average 2.9/5 across 10 of 10 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'objective and unbiased' analysis and specifies output formatting, but doesn't disclose critical behavioral traits like whether this is a read-only operation, what permissions are needed, rate limits, or how the analysis is performed (e.g., algorithmic vs. human).
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?
Four sentences with some redundancy ('You are a sentiment analysis tool' repeats the name). The output formatting instruction is useful but could be more efficiently integrated. The description is reasonably short but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a sentiment analysis tool with 4 parameters and no annotations or output schema, the description is inadequate. It doesn't explain the relationship between parameters, how sentiment is determined from the inputs, what the tool actually does with the provided data, or what the analysis output contains beyond formatting instructions.
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 fully documents all 4 parameters. The description adds no meaningful parameter semantics beyond what's in the schema - it mentions 'provided rationale' which corresponds to the 'reasoning' parameter but doesn't elaborate on its purpose or format.
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 states 'analyze the sentiment for the given stock symbol' which provides a basic verb+resource, but it's vague about what 'analyze' entails and doesn't distinguish from siblings like search_news or get_ticker_news that might also provide sentiment insights. The opening 'You are a sentiment analysis tool' is tautological with the name.
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 on when to use this tool versus alternatives like search_news for sentiment-related information. The description mentions 'Based on the provided rationale' but doesn't explain what constitutes appropriate rationale or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action and source but lacks details on permissions, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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 with zero wasted words. It front-loads the core purpose and includes essential context (Yahoo Finance API), making it appropriately sized and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It covers the basic purpose but omits critical behavioral details (e.g., response format, error cases) and usage guidelines relative to sibling tools, which are needed for effective agent operation.
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 input schema already documents the 'symbol' parameter fully. The description adds no additional meaning or context beyond what the schema provides, such as examples or formatting details, meeting the baseline for high 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 action ('Retrieve information') and target resource ('about a specific stock symbol'), with the specific source ('Yahoo Finance API') adding useful context. It doesn't explicitly differentiate from sibling tools like 'search_quote' or 'get_ticker_news', 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?
No guidance is provided on when to use this tool versus alternatives like 'search_quote' or 'get_ticker_news'. The description implies usage for stock symbol information but offers no explicit context, exclusions, or comparisons with sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states the tool fetches news but doesn't describe what 'fetches' entails—e.g., whether it returns recent articles, a limited number, requires authentication, has rate limits, or handles errors. This leaves significant gaps in understanding the tool's 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 that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal 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 complexity of fetching news (which can involve recency, volume, or format considerations), no annotations, and no output schema, the description is incomplete. It doesn't address what the output looks like (e.g., list of articles, summaries), potential constraints, or how it differs from sibling tools, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a given stock ticker symbol,' which aligns with the single parameter 'symbol' in the input schema. Since schema description coverage is 100% (the schema already describes 'symbol' as 'The stock symbol'), the description adds no additional semantic value beyond what's in the schema, meeting the baseline for high 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 action ('fetches') and resource ('news articles') with a specific scope ('for a given stock ticker symbol'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_news' or 'get_ticker_info', which could provide similar or overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'search_news' (which might allow broader queries) or 'get_ticker_info' (which might include news as part of broader data). There's no mention of prerequisites, limitations, or typical use cases beyond the basic function.
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. The description only states what the tool does ('Retrieve'), but doesn't disclose any behavioral traits such as whether this is a read-only operation, what data format is returned, potential rate limits, authentication requirements, or error conditions. For a tool with no annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core functionality 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 that there are no annotations and no output schema, the description is incomplete for a tool that presumably returns company data. It doesn't explain what 'top' means (by what metric?), what data is returned about each company, the format of the response, or any limitations. For a retrieval tool with rich sibling tools and no structured output documentation, 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 input schema has 100% description coverage, with both parameters clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it mentions 'specific sector' which aligns with the 'sector' parameter but provides no additional context about parameter usage, constraints, or examples. The baseline score of 3 is appropriate when 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 ('Retrieve') and target resource ('top companies in a specific sector'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_top_etfs', 'get_top_growth_companies', or 'get_top_performing_companies', which all retrieve top items but for different categories.
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, prerequisites, or specific contexts where this tool is preferred over others like 'get_top_growth_companies' or 'get_top_performing_companies'. The agent must infer usage from 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 but adds minimal context. It implies a read-only operation but doesn't specify aspects like rate limits, authentication needs, return format (e.g., list size, data fields), or error handling, which are critical for a 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for its purpose, earning full marks 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'top' means (e.g., by market cap, performance), the return format, or any behavioral traits, leaving significant gaps for a tool that likely returns structured data.
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, clearly defining the 'sector' parameter with an enum list. The description adds no additional semantic context beyond implying sector filtering, so it meets the baseline of 3 without compensating for any gaps.
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 ('Retrieve') and resource ('top ETFs in a specific sector'), making the purpose understandable. However, it doesn't distinguish this tool from potential siblings like 'get_top_companies' or 'get_top_mutual_funds' beyond the ETF focus, which is implied but not explicitly contrasted.
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 like 'get_top_companies' for broader results or 'get_ticker_info' for individual ETF details, leaving usage context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Retrieve', implying a read operation, but doesn't cover aspects like rate limits, authentication needs, data freshness, or what 'growth' means (e.g., based on metrics like revenue or stock performance). This leaves significant gaps for a tool with no structured safety hints.
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 unnecessary words. It's front-loaded and appropriately sized, making it easy for an 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 complexity of a tool that retrieves ranked data (implying sorting and criteria like 'growth'), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'growth' entails, the data source, return format, or error handling, making it inadequate for reliable agent use without additional context.
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 with clear descriptions for both parameters ('sector' and 'top_n'). It implies filtering by sector but doesn't explain semantics like how 'growth' is measured or default behaviors. With high schema coverage, the baseline is 3, as the description doesn't significantly enhance parameter understanding.
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 ('Retrieve') and resource ('top growth companies in a specific sector'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_top_companies' or 'get_top_performing_companies', which might have overlapping functionality, so it lacks sibling 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. It doesn't mention prerequisites, exclusions, or compare to siblings such as 'get_top_companies' or 'get_top_performing_companies', leaving the agent with no usage context beyond the basic purpose.
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 operation ('Retrieve') but doesn't address performance aspects like rate limits, data freshness, pagination, or what defines 'top performing' (e.g., metrics, time frame). This is inadequate for a tool with potential complexity in ranking logic.
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. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured for quick comprehension.
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 effective tool use. It doesn't explain what 'top performing' means (e.g., by revenue, stock performance), how results are returned, or error handling. For a ranking tool with undefined output, more context is needed to guide the agent properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'specific sector' which aligns with the 'sector' parameter, but adds no semantic details beyond what the schema provides (which has 100% coverage with clear descriptions and enums). For 'top_n', it doesn't clarify constraints like valid ranges or defaults. With high schema coverage, the baseline score of 3 is appropriate as the description adds minimal 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 ('Retrieve') and resource ('top performing companies in a specific sector'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from similar sibling tools like 'get_top_companies' or 'get_top_growth_companies', which would require more specific language about performance metrics or ranking criteria.
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_top_companies' or 'get_top_growth_companies'. It mentions 'specific sector' but doesn't clarify prerequisites, exclusions, or comparative use cases with sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Search for news articles') but fails to describe key behaviors: it doesn't specify the source or scope of news, potential rate limits, authentication needs, error handling, or the format of returned results. For a search 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 directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly. This exemplifies good conciseness and structure for a simple tool.
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 as a search function with no annotations and no output schema, the description is incomplete. It doesn't explain what the search covers, how results are returned, or any limitations. For a tool that likely returns multiple articles, more context on result format, pagination, or sorting would be helpful to ensure proper usage by an agent.
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 both parameters ('query' and 'news_count') clearly documented in the schema. The description mentions 'using a query string', which aligns with the 'query' parameter but adds no additional semantic context beyond what the schema provides. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description offers minimal 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 verb ('Search for') and resource ('news articles') with the mechanism ('using a query string'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_ticker_news' or 'search_quote', which might also retrieve news-related information, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools such as 'get_ticker_news' or 'search_quote', which could be relevant for news retrieval. This lack of differentiation leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic function but doesn't mention important traits like whether this is a read-only operation, what data sources it queries, rate limits, authentication requirements, or what happens when no results are found. This leaves significant gaps for an 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 extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential function 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 lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the tool returns (e.g., quote data format, error handling), nor does it provide context about the search scope or limitations. For a search tool with no structured behavioral hints, this leaves too much unspecified.
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 both parameters ('query' and 'max_results') well-documented in the schema. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline for high schema coverage without compensating with extra insights.
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 ('search for quotes') and resource ('quotes'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'search_news' or explain what kind of quotes it searches for (stock quotes, famous quotes, etc.), 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 like 'search_news' or other sibling tools. It doesn't mention prerequisites, limitations, or specific contexts where this search is appropriate versus other quote-related operations that might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data but doesn't specify whether this is a read-only operation, if it requires authentication, has rate limits, returns a list or single item, or includes pagination. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to understand at a glance.
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 (one parameter with full schema coverage but no output schema or annotations), the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format, which are important for an AI agent to use it correctly without structured 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?
The input schema has 100% description coverage, with the 'sector' parameter well-documented via an enum list. The description adds minimal value beyond the schema by implying the sector is used to filter mutual funds, but it doesn't provide additional context like what 'top' means (e.g., by performance, assets) or how many funds are returned.
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 ('Retrieve') and resource ('top mutual funds in a specific sector'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_top_etfs' or 'get_top_companies', which might retrieve similar financial data but for different asset classes or entities.
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_top_etfs' for ETFs or 'get_top_companies' for stocks. It lacks context on prerequisites, such as needing a specific sector input, and doesn't mention any exclusions or complementary tools.
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:

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

Score Badge

Copy to your README.md:

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

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/thirdstrandstudio/mcp-yeoman'

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