Trading MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Each tool targets a specific analysis domain (insider, news, Reddit, fundamentals, etc.), but there is slight overlap between analyze_reddit_sentiment and discover_trending_stocks (both use Reddit), and comprehensive_stock_analysis duplicates the functionality of many individual tools. Nonetheless, the descriptions clearly differentiate their purposes.
Naming Consistency4/5All tools use snake_case with action verbs (analyze, calculate, compare, discover, get, screen). There is one outlier (comprehensive_stock_analysis) that uses a phrase rather than verb_noun, but the pattern is mostly consistent.
Tool Count5/510 tools is well-scoped for a trading analysis server. Each tool provides a distinct function without being overwhelming, and the count aligns with typical MCP server sizes for this domain.
Completeness4/5The tool set covers fundamental analysis, valuation, sentiment (news, Reddit, options), insider activity, screening, and trending detection. Missing technical analysis and risk metrics, but overall it's a robust coverage for a stock analysis server.
Average 4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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.jsonto 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?
No annotations provided, so description carries burden. It describes a read-only, comprehensive analysis, but lacks details like data source, freshness, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with some redundancy (first and third sentences repeat similar content). Could be more concise while retaining key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must explain returns. Lists example metrics but doesn't detail output structure or how to handle partial results. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds examples and emphasizes selective retrieval, but doesn't substantially extend schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves fundamental stock metrics with specific examples (P/E, PEG, ROE, etc.). Distinct from sibling tools like sentiment or insider analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use when conducting deep fundamental analysis for investment decisions'. Provides context but no explicit when-not or alternatives.
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 provided, so description carries full burden. It mentions output structure (breakdowns, insights) but does not disclose behavioral traits such as data source, side effects, rate limits, or read-only status. Minimal transparency beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value. Purpose is front-loaded. No redundant or irrelevant information. Efficiently communicates the tool's function, use case, and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains input (ticker, custom weights), processing (profitability, liquidity, etc.), and output (0-100 score with breakdowns). Without an output schema, the description adequately covers the return structure. Could mention limitations or data freshness, but overall complete for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context for the weights parameter ('custom weighting to match your investment strategy'), but does not provide additional semantic details beyond what the schema includes. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates a comprehensive financial health score based on multiple metrics, and specifies the return value (0-100 weighted score). It distinguishes from sibling tools by focusing on overall financial strength rather than specific aspects like insider activity or sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this when evaluating the overall financial strength of a company for investment decisions, risk assessment, or portfolio screening.' Missing explicit 'when not to use' or alternative suggestions, but context is clear.
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 exist, so the description bears full burden. It describes outputs ('Returns analyzed articles with sentiment scores...') but does not disclose behavioral traits like rate limits, authentication needs, or potential side effects. It implies a read-only analysis tool, but lacks explicit safety or constraint details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) with front-loaded purpose, followed by usage context and outputs. The final sentence ('Essential for making informed investment decisions...') is somewhat generic but does not significantly detract. The structure is logical and economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema, no annotations), the description adequately covers purpose, usage, and return value. It does not explain side effects or prerequisites, but for an analysis tool, these are less critical. The description is largely sufficient for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so parameters are well-documented in the schema. The description adds no additional parameter-level meaning beyond stating that 'sector' is optional and 'news_items' is optional. Baseline 3 is appropriate as the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Comprehensive news and market analysis tool' combining sentiment, market impact, and sector context. It uses specific verbs and resources ('analyze news and market context') and distinguishes itself from sibling tools like 'analyze_reddit_sentiment' or 'get_fundamental_stock_metrics' by focusing on current events and market trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use: 'when researching current events affecting a stock, evaluating news-driven price movements, or understanding how individual stocks fit into current market trends.' It does not provide explicit when-not-to-use instructions or alternatives, but the context is clear and sufficient for most agents.
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 full burden. It mentions parallel execution of analyses and conditional inclusion of news/Reddit sentiment, but lacks details on behaviors such as rate limits, data freshness, or latency. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and lists included analyses. It is concise with no wasted words, though a more structured format (e.g., bullet points) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description adequately explains that it returns a formatted report with analysis results and insights. It covers key behaviors, though it omits potential limitations like API costs or timeouts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'ticker', is described in the input schema as 'Stock ticker symbol to analyze'. The tool description does not add additional meaning beyond this, and schema coverage is 100%, so the description adds no extra value for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as combining multiple analyses (fundamental metrics, financial health, insider trading, put/call ratio, and optional news/Reddit sentiment) to provide a complete investment evaluation. It distinguishes itself from sibling tools that focus on individual analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'when you need a complete overview of a stock across all analysis dimensions for investment decision-making.' This provides clear usage context, though it does not explicitly contrast with sibling tools by stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses returns (transaction history, sentiment, confidence scores) but lacks details on data freshness, sources, or rate limits. The behavioral info is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a distinct purpose: scope, functionality, output, and usage. No redundancy or fluff, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description outlines return values (transaction history, sentiment, confidence scores). It does not cover pagination or error handling, but given the tool's complexity, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds general context (e.g., 'buy/sell activity') but does not enhance parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: comprehensive insider trading analysis including transaction monitoring and sentiment evaluation. It distinguishes itself from sibling tools (e.g., news, Reddit sentiment) by focusing specifically on insider activity, making selection unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is 'essential for identifying stocks with strong insider support or potential red flags,' providing clear context for use. However, it does not explicitly exclude scenarios or mention alternatives, so it receives a 4 rather than 5.
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 states the tool returns 'a comparative analysis with P/E, PEG, Price-to-Book ratios and highlights relative value opportunities,' but lacks details on side effects, prerequisites, rate limits, or data freshness. The description is positive and promotional, missing behavioral traits like data recency or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. The first sentence states purpose, the second provides usage context, and the third describes output. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description covers purpose, usage context, and key output highlights. It does not mention error cases, maximum tickers, or data source, but for a simple comparative tool, it provides essential information for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds some context by explaining the output (which metrics are returned), but it does not elaborate on parameter meanings or usage constraints beyond what the schema provides. The value added is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'relative valuation analysis tool' that compares key metrics across multiple stocks, specifying the verb (compare) and resource (stock valuations). It distinguishes itself from siblings like 'get_fundamental_stock_metrics' by focusing on relative comparison for peer analysis or sector comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage contexts: 'when performing peer analysis, sector comparisons, or evaluating multiple investment candidates side-by-side.' It does not mention when not to use the tool or alternative tools, but the given guidance is clear and sufficient.
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, description discloses output format (ranked lists, metrics) but lacks details on data freshness, limitations, or potential biases. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, no fluff. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return values (ranked lists, sentiment, engagement metrics). Covers purpose, usage, and basic parameters completely for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, description adds context like 'Reddit investing communities' for subreddits and 'trending tickers' for limit, but does not significantly extend beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a social momentum detection for Reddit stocks, with specific verbs like 'identifies', 'detecting', and distinguishes from siblings by focusing on trending/meme stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: looking for emerging opportunities, viral movements, meme stock candidates. Does not mention alternatives or when not to use, but context of siblings provides some guidance.
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 bears full responsibility. It discloses the tool searches multiple subreddits, optionally extracts comments, and performs AI sentiment classification with confidence scores, key themes, and engagement metrics. It doesn't mention rate limits or auth needs, but these are less critical for a read-only analysis 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the core purpose and use case. It is efficient but could be trimmed slightly for maximal conciseness. Each sentence adds value, earning a score of 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters (1 required), no output schema, and no annotations, the description covers the workflow: search, optional comment extraction, sentiment analysis, and returns (posts, sentiment with confidence, themes, engagement). It provides sufficient context for an agent to understand tool capabilities and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. The description adds high-level context (e.g., 'combines Reddit post search, optional comment extraction, and advanced sentiment classification') but does not provide parameter-specific details beyond what the schema already documents. This meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'comprehensive Reddit sentiment analysis tool' that searches stock discussions across multiple investing subreddits and uses AI to analyze sentiment. It differentiates from sibling tools (e.g., fundamental analysis, insider activity) by focusing specifically on social sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this when assessing retail investor sentiment, detecting sentiment shifts, or validating investment decisions against community consensus.' It lacks explicit when-not-to-use guidance, but usage context is clear given siblings cover different domains.
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 provided; description carries full burden. It states the tool returns a ranked list with key metrics, but does not disclose read-only nature, auth requirements, rate limits, or error handling. For a screening tool, this is partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear purpose, usage, and output. It is slightly verbose but each sentence contributes. Front-loads the main function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity and no output schema, description covers purpose, usage, and return content. It lacks explanation of potential errors or edge cases, but is fairly complete for a screening tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant value by explaining Finviz format ('ta_pattern_*', 'cap_large'), the 'f' and 'o' structure, and providing examples. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('screen') and resource ('stocks using Finviz filters'), and lists supported criteria (technical patterns, fundamental criteria, multi-parameter). It distinguishes from sibling tools like discover_trending_stocks and get_fundamental_stock_metrics by focusing on advanced Finviz-based screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios ('when you need to find stocks matching specific investment criteria like channel down patterns, profitable companies, or large-cap stocks'). It does not list when not to use, but the examples and context imply appropriate use cases relative to siblings.
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 provided, the description carries full burden. It details what the tool returns (ratios for different expirations, volume, open interest, AI sentiment) and how to interpret high/low ratios. It does not mention any limitations, data update frequency, or authentication needs, but adequately discloses behavior for a read-only data 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: core function, usage scenarios, and output description plus interpretation. It is front-loaded and concise with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description adequately covers purpose, usage, output details, and interpretation. It could mention data source reliability or freshness, but overall it is complete enough for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'ticker' described as 'Stock ticker symbol'. The description adds context about the data retrieved but does not extend the parameter's meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves put/call ratio data from Barchart to assess market sentiment and options flow, distinguishing it from sibling tools that focus on different analysis areas like insider activity, reddit sentiment, or financial health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (analyzing options market sentiment, detecting reversals, understanding hedging) but does not mention when not to use it or compare it to related sibling tools like analyze_reddit_sentiment or analyze_news_and_market_context.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/netanelavr/trading-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server