Agentic-Investor

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct aspect of investing (technical analysis, intraday data, sentiment indices, fundamentals, etc.). While get_price_history and fetch_intraday_data both provide price data, their granularities are clearly different (daily vs 15-min), and get_ticker_data combines current price with fundamentals, avoiding confusion.
Naming Consistency4/5
Most tools follow a 'get_noun' pattern (e.g., get_earnings_history, get_price_history), with exceptions: calculate_technical_indicator and fetch_intraday_data. This slight inconsistency is minor and still clear.
Tool Count5/5
14 tools is well-scoped for an investing research server, covering technical, fundamental, sentiment, and market data without being overwhelming.
Completeness4/5
The tools provide comprehensive coverage for stock and crypto research, including history, fundamentals, options, and sentiment. Minor gaps exist (e.g., no multi-ticker comparison or direct execution), but core workflows are supported.
Average 4.2/5 across 14 of 14 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
No annotations are provided, so the description carries full burden. It explains the scale and indicates historical data and trend analysis are included, but lacks details on data freshness, authentication, or rate limits, which are important for a tool accessing an external API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first defines the tool, the second provides usage context and capabilities. It is efficiently worded, though could benefit from slight restructuring to separate purpose from usage guidance.
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 simple input (one parameter) and no output schema, the description should fully cover usage. It explains the output but leaves the input parameter entirely undocumented, making the tool incomplete for an agent to invoke correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'input_data' with no defined properties and 0% schema coverage. The description does not explain what this parameter expects, leaving the agent without guidance on how to structure the input, thus failing to add meaning beyond the minimal 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 clearly states the tool retrieves the Crypto Fear & Greed Index from Alternative.me on a 0-100 scale, and distinguishes it from the sibling get_cnn_fear_greed_index by specifying the source. It provides specific verb and resource, making the purpose unmistakable.
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 explicitly lists use cases such as crypto market sentiment, investor psychology, and timing buy/sell decisions, giving clear context for when to invoke. However, it does not specify when not to use or mention alternative 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?
Without annotations, the description discloses key behaviors: supports quarterly/annual frequencies, up to 20 periods, and returns structured data. It does not mention idempotency, error handling, or data source, but covers main aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the purpose. It lists many line items which adds verbosity but is helpful. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should cover return format. It states 'structured format with all line items' which is vague but adequate with the examples. Given the tool's complexity, more detail could be added.
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 already contains detailed descriptions and examples for each parameter. The description adds context by explaining what the returned data contains, but does not add new parameter-level meaning beyond what the schema provides.
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 it retrieves detailed financial statements, listing specific line items like income statements, balance sheets, and cash flow statements. It is distinct from sibling tools which focus on price history, options, or technical indicators.
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 explicitly states when to use the tool, e.g., 'when asked about company financials, revenue trends, profitability,' and provides example queries. It does not explicitly state when not to use, but the 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 are provided, so the description carries the full burden. It explains the scale (0=extreme fear, 100=extreme greed) and enumerates the seven indicators, but does not disclose side effects, network dependencies, or caching 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 two sentences: the first defines the tool and its components, the second provides usage guidance. No redundant words, front-loaded with key information.
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 data retrieval tool with one parameter and no output schema, the description covers purpose, components, and usage. However, it lacks details about the output format, which would enhance completeness.
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 already describes the 'indicators' parameter with a clear description and default. The tool description does not add meaning beyond the schema; it mentions the indicators in general but not how to specify them via the parameter.
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 explicitly states the tool retrieves CNN's Fear & Greed Index with a 0-100 scale and lists seven specific indicators. It distinguishes from sibling 'get_crypto_fear_greed_index' by specifying 'stock market 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear directive: 'Use this when asked about...' with specific scenarios like market sentiment and investor psychology. It provides context but does not mention exclusions or alternatives.
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 must disclose behavior. It states the tool 'Returns up to 100 recent trades' and lists output fields. However, it does not specify the recency window, whether data is real-time or delayed, or any access limitations.
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 informative with an example and use cases. Slightly verbose but well-structured, with key information front-loaded.
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?
No output schema exists, but the description fully enumerates the 7 fields returned (insider name, title, transaction type, share count, price per share, total value, filing date), making the tool's output predictable.
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 coverage is 100% (both parameters described in schema). The description adds examples but does not substantially enhance understanding beyond the schema's own 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 combination: 'Get recent insider trading activity'. It clearly distinguishes the tool's purpose from sibling tools like get_price_history or get_financial_statements by listing exact transaction types and citing example queries.
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?
Explicit use cases are provided (e.g., 'when asked about insider buying/selling', 'Are AAPL insiders buying?') and interpretive context ('Heavy insider buying can signal confidence while selling may indicate concerns'). However, it does not explicitly state when not to use this tool.
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 discloses behavioral traits: 15-minute resolution, returns timestamp and close price, EST timezone, max 1000 bars (~10 trading days), and data source (Alpaca). It does not cover rate limits or authentication, but provides key 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, front-loaded with the core action, and provides usage guidance without unnecessary words. It is efficient but could be slightly more concise.
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?
Given the tool's simplicity (2 params, no output schema), the description covers input constraints, output format, and use cases. It lacks data delay or error handling info, but is adequately complete for a straightforward data fetch tool.
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 0% (description doesn't include parameter descriptions), but the schema itself describes parameters well. The description adds context about output (timestamp, close price) and the max bars limit, partially compensating for low coverage. However, it doesn't elaborate on parameter details beyond the 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 clearly states the tool fetches high-resolution 15-minute stock price data, specifying the verb 'fetch', the resource 'intraday stock price data', and distinguishes from siblings like get_price_history by emphasizing intraday granularity.
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 explicitly states when to use the tool (e.g., intraday price action, today's trading pattern) and provides example queries. However, it does not mention when not to use it or explicitly reference sibling alternatives.
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 discloses that it returns top 20-100 largest holders and explains output fields. It mentions high institutional ownership as a signal, which adds context. It does not discuss rate limits or authorization, but for a read-only data tool, this is sufficient.
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 front-loaded with the action and includes examples, but it is slightly verbose with multiple clauses. It could be more concise, but the information is well-organized.
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?
Given no output schema, the description explains return fields (position sizes, shares, etc.). It provides use cases and examples. Missing details like error handling or pagination, but the tool is simple and the description covers core aspects.
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 already provides descriptions for ticker and top_n, including default and range. The description only adds that top_n returns 20-100 holders, which is already in the schema. It does not add new parameter-specific meaning beyond what the schema offers.
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 it retrieves major institutional shareholders and mutual fund holders, including specific data fields like position sizes and share counts. It distinguishes itself from sibling tools (e.g., get_insider_trades, get_price_history) by focusing on institutional ownership.
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 explicitly tells when to use this tool (e.g., 'when asked about institutional ownership') and provides example queries. It does not mention when not to use it or alternative tools, but the provided examples and context are adequate for guiding usage.
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?
No annotations provided, so the description carries full burden. It comprehensively lists all returned data points: price, volume, P/E, news, recommendations, upgrades, earnings calendar. It is clearly a read-only operation with no destructive behaviors, though rate limits and authentication are not mentioned.
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 a single paragraph that front-loads the main purpose and then lists multiple output categories. It is dense but not verbose, with no wasted sentences.
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?
Given the complexity and no output schema, the description adequately covers the return values: fundamentals, news, recommendations, upgrades, earnings calendar. It is complete enough for an agent to understand what the tool provides.
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 is self-documenting with descriptions for each parameter (e.g., ticker, max_news). The tool description does not add additional parameter semantics beyond what the schema provides. Schema coverage is 0% from the description, but the schema itself is 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?
The description clearly states the tool's purpose: 'Get comprehensive stock analysis including...' with a long list of specific data points. It distinguishes itself from sibling tools like get_earnings_history or get_options by offering a broad overview covering fundamentals, news, recommendations, and more.
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?
Explicitly states when to use: 'Use this when asked about stock performance, company valuation, fundamentals, Wall Street sentiment, analyst opinions, recent company news, or financial health.' It does not specify when not to use, but the sibling list implies alternatives.
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?
The description discloses that the tool returns normalized interest scores (0-100) and gives example keywords, but it does not mention any behavioral traits such as rate limits, authentication requirements, or potential data limitations. Since no annotations are provided, the description carries the full burden, and while it provides some useful behavioral context, it lacks completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a use-case list and examples. It is front-loaded with the core purpose, and every sentence adds value without unnecessary detail. Extremely concise for the information provided.
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 tool with two parameters and no output schema, the description covers the essential aspects: what it does, when to use it, and example usage. It could be slightly more complete by mentioning the default period (7 days) or that the output is an array of data points, but it is largely sufficient.
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?
Despite the input schema having 0% description coverage (according to context signals), the description adds meaning by mentioning 'specified keywords over customizable time periods (7, 30, 90+ days)' and providing example keywords like 'bitcoin', 'Tesla earnings', 'inflation'. This helps the agent understand parameter usage beyond the schema's structural 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 explicitly states 'Get relative search interest data from Google Trends for specified keywords over customizable time periods' and mentions the output format (normalized 0-100 scores). It clearly distinguishes this tool from siblings like get_price_history or get_market_movers, which cover different domains.
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 a detailed list of when to use the tool: 'Use this when asked about public interest trends, search volume comparisons, trending topics, brand awareness over time, seasonal patterns, or correlation between search interest and stock movements.' It does not explicitly state when not to use it, but the context is clear.
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, description carries full burden. It discloses it returns up to 100 stocks with price, volume, and percentage change, and indicates real-time/recent sessions. No mention of auth needs or rate limits, but adequate for a read 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?
Four sentences, each with clear purpose: function, usage, filtering, output. No redundant information. Front-loaded with purpose and usage.
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?
Given no output schema, description covers return data (price, volume, percentage change). Parameter count is low and explained via schema and description. Slightly lacking in full parameter detail but sufficient for agent 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?
Schema coverage is 0%, but description adds value by explaining filtering by market session and categories implicitly. The schema itself provides enums and descriptions, but the tool description does not describe the input_data structure directly, relying on the 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?
Clearly states the tool identifies top gainers, losers, and most active securities by volume. Provides specific synonyms like 'what's hot' and 'what's moving', distinguishing it from sibling tools that retrieve other data.
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?
Explicitly lists usage scenarios, including phrases like 'what's hot', 'market leaders', and 'pre-market activity'. Supports filtering by market session but doesn't mention when not to use, though context is clear.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns up to 50 reports and includes key data fields. It implies read-only historical access, which is appropriate for a data retrieval tool. Could explicitly state 'read-only' for clarity.
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, front-loaded with purpose, includes usage guidance, and example queries. Every sentence adds value without redundancy.
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 has no output schema, so the description compensates by listing the data fields returned (EPS estimates, actuals, surprises, dates). For a simple data retrieval tool with 1 parameter, this is complete and sufficient.
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 provides detailed descriptions for both parameters (ticker, max_entries) with defaults and constraints. The description adds minimal extra meaning beyond noting the 50-entry limit already in the schema. Given schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical quarterly earnings results with specific data points (EPS estimates, actuals, surprises, dates). It distinguishes this tool from sibling 'get_nasdaq_earnings_calendar' by focusing on historical data rather than upcoming events.
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 explicitly lists when to use the tool (e.g., earnings beats/misses, consistency, trends) and provides example queries. It does not explicitly state when not to use it, but the context is clear and differentiates from sibling tools.
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?
Without annotations, the description discloses use of TA-Lib, customizable periods, lookback windows, and a return limit of 1000 data points. It lacks details on error handling and data source reliance, but is transparent about its core behavior.
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 informative but slightly verbose. It is well-structured with a clear hierarchy: purpose, list of indicators, use cases, customization, and examples. Could be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers purpose, parameters, and return limit but fails to specify the return format (e.g., data points with dates and values). This gap reduces 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?
Schema parameter descriptions cover all parameters, giving a baseline of 3. The description adds value by explaining usage context, providing examples, and grouping parameters by indicator, enhancing understanding beyond the 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 clearly states the tool calculates technical indicators using TA-Lib and lists specific indicators (SMA, EMA, RSI, MACD, BBANDS). It differentiates from sibling tools like get_price_history by specifying use cases for technical analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool, such as for overbought/oversold conditions, trend identification, and momentum signals. It also hints at alternatives by listing sibling tools.
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 full burden. It discloses behavioral traits: 'Returns up to 500 companies' (limit), 'Defaults to today's date if not specified'. It implies read-only and safe operation but could mention lack of side effects explicitly.
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 4-sentence paragraph with no wasted words. It front-loads the main purpose and every sentence adds value: outputs, limit, usage scenarios, examples.
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?
Given no output schema, the description adequately explains return fields (company names, ticker, estimates). It also covers the date default and limit. Could mention error handling or response structure for missing data, but sufficient for typical use.
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?
Schema description coverage is 0% for the top-level parameter, but the description adds meaning: explains date format, default behavior, and maximum limit. It compensates well, though the nested schema structure is not clarified.
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 specifies the verb 'Get upcoming earnings announcements' and the resource 'for a specific date' with detailed outputs (company names, ticker, EPS estimates, etc.). It distinguishes from siblings like get_earnings_history by focusing on calendar date rather than 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 'Use this when asked about earnings calendar, who reports today/tomorrow...' and gives example queries. It does not explicitly state when not to use it or alternatives, but the context is clear and helpful.
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?
Discloses smart interval selection (daily for longer, intraday for shorter). No annotations, so description carries burden. Sufficient for data retrieval, though lacks rate limits or error info.
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?
Concise, front-loaded with purpose, then usage guidance and details. Every sentence adds value. No 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?
Adequately covers purpose, usage, and data for a simple tool with no output schema. Could include return format, but not essential given clarity.
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?
Description adds meaning beyond schema: explains interval logic and lists periods in readable form. Schema covers basic param descriptions, but description enriches with usage context.
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 clearly states 'Get historical OHLCV stock price data with smart interval selection', specifying verb and resource. It distinguishes from sibling tools like fetch_intraday_data by mentioning intraday for short periods.
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?
Explicitly lists scenarios when to use (e.g., 'price history, past performance, stock charts') and supported periods. Lacks explicit 'when not to use' 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.
Behavior4/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 discloses the return limit (1000 contracts) and filtering options. However, it does not explicitly state idempotency/read-only nature, though it is implied. Nearly complete.
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 well-structured, front-loading purpose, then usage, filtering, limits, and examples. Every sentence adds value with no redundancy.
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?
Given the complexity of options data and lack of output schema, the description covers all essential aspects: return data, filtering, limits, and example queries. It is sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by explaining how filtering parameters (strike range, expiration window, option type) work together. While the schema has detailed descriptions for each parameter, the description provides usage context, compensating for the 0% reported coverage (likely a measurement issue).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves options chain data, listing specific data points (strike prices, Greeks, etc.) and filtering capabilities. It uses specific verbs and distinguishes this tool from siblings by focusing exclusively on options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use this when asked about options strategies...' and provides concrete examples. Although it doesn't directly contrast with siblings, the sibling list contains no other options tool, and the description covers key usage scenarios.
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:

[![agentic-investor MCP server](https://glama.ai/mcp/servers/jon-fox/agentic-investor/badges/card.svg)](https://glama.ai/mcp/servers/jon-fox/agentic-investor)

Score Badge

Copy to your README.md:

[![agentic-investor MCP server](https://glama.ai/mcp/servers/jon-fox/agentic-investor/badges/score.svg)](https://glama.ai/mcp/servers/jon-fox/agentic-investor)

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/jon-fox/agentic-investor'

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