Stocklake — AI Stock Intelligence
Server Details
AI stock intelligence: prices, fundamentals, technicals, news, macro regime, and sector signals.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 20 of 20 tools scored. Lowest: 3.8/5.
Every tool has a clear, distinct purpose. Overlaps like search_stocks vs get_screener are clarified by descriptions (simple vs advanced), and get_stock_rating vs get_technical_signals serve different formats. No two tools are easily confused.
Most tools follow a 'get_<noun>' pattern. The only deviation is 'search_stocks', which is a search operation, not a retrieval. This is a minor break in the otherwise consistent naming scheme.
20 tools is well-scoped for a stock intelligence server covering fundamentals, AI analysis, market data, sectors, and screening. Each tool earns its place without overwhelming the agent.
The tool surface covers the full research workflow: individual stock data, batch queries, history, news, AI summaries, ratings, technical signals, sentiment, sector analysis, market assessment, and discovery ideas. No obvious gaps for the intended purpose.
Available Tools
20 toolsget_discovery_ideasGet Discovery IdeasARead-onlyIdempotentInspect
AI-screened stock ideas actively flagged by the Stocklake pipeline. These are stocks the pipeline's AI agents have identified as worth attention — sourced from news analysis, sector screening, and sentiment signals.
Parameters:
direction: "LONG" | "SHORT" | "BOTH" (default: all)
min_conviction: minimum conviction score 0-10 (default 7)
min_flag_score: minimum flag score 0-10 (default 8; 9+ = high conviction)
source: filter by signal source — "news" | "screener" | "sentiment" (default: all)
limit: max results to return (default 25, max 50)
Returns:
count: number of ideas returned
ideas[]: each with symbol, direction, conviction (0-10), confidence (0-10), flag_score (0-10), source, rationale, expires
Note: ideas expire daily — active ideas represent the pipeline's current view.
Pro tier only — AI pipeline cost attached. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| source | No | ||
| direction | No | ||
| min_conviction | No | ||
| min_flag_score | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, non-destructive. Adds expiration detail, return fields, and disclaimer. No contradiction, adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for parameters and returns. Every sentence adds value. Front-loaded with purpose. Appropriate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, parameters, return structure, expiration, cost, disclaimer. Complete for a read-only lookup tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, description fully compensates: explains all 5 parameters with defaults, ranges, possible values (e.g., direction: LONG/SHORT/BOTH). Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'get_discovery_ideas' returning AI-screened stock ideas. Distinguishes from siblings like get_market_movers or get_stock by specifying pipeline's AI agents and sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes context: AI-screened ideas from pipeline, daily expiry, Pro tier cost. Implies when to use but no explicit when-not or alternatives. Still clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_earnings_calendarGet Earnings CalendarARead-onlyIdempotentInspect
Upcoming earnings dates for stocks in the Stocklake universe.
days: look-ahead window in days (default 7, max 30)
Returns: { window_days, from_date, to_date, count, results[] }
Each result: symbol, name, sector, market_cap, price, rsi, earnings_date (ISO UTC), is_estimate, eps_trailing, eps_forward
Sorted by earnings_date ascending.
Dates sourced from market data — treat is_estimate=true dates as approximate. Available to all tiers.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds important behavioral context beyond annotations: data sourced from market data, is_estimate=true dates are approximate, sorted ascending by earnings_date. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear first line, bullet points for parameters and return fields, and a note on data source. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a read-only, idempotent tool with an output schema. Covers parameters, return structure, sorting, and data source caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing the 'days' parameter: look-ahead window, default 7, max 30. Also describes return structure and field semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Upcoming earnings dates for stocks in the Stocklake universe.' This is a specific verb-resource pair that distinguishes it from siblings like get_earnings_intelligence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (need upcoming earnings dates) and notes 'Available to all tiers,' but does not explicitly list when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_earnings_intelligenceGet Earnings IntelligenceARead-onlyIdempotentInspect
Upcoming earnings with AI context — flag scores, verdicts, and risk factors per stock. Combines the earnings calendar with AI pipeline data to surface which upcoming earnings events are worth monitoring.
Parameters:
days_ahead: look-ahead window in days (default 14, max 30)
sector: filter to one sector (e.g. "Technology")
min_flag_score: only return stocks with AI flag score >= this value (optional)
Returns per stock (sorted by earnings_date ascending):
earnings_date: ISO UTC timestamp · is_estimate: whether date is estimated
symbol, name, sector, price, rsi, market_cap
eps_trailing, eps_forward (earnings expectations context)
ai_verdict, ai_flag_score, ai_confidence (nightly AI pipeline)
ai_risks: top 2 AI-identified risk factors
analyst_rating, analyst_target
Pro tier only — AI pipeline cost attached. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No | ||
| days_ahead | No | ||
| min_flag_score | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it is 'Pro tier only' with cost and sorts by earnings_date. This provides some extra context beyond annotations but does not significantly deepen behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a leading summary, parameter list, and return details. However, since an output schema exists, the detailed return field listing is redundant. Some sentences like 'For informational purposes only. Not financial advice.' are unnecessary. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still covers the tool's purpose, parameters, return fields, and usage note (Pro tier cost). It is thorough, though it could briefly mention how it differs from the earnings calendar tool for better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the structured schema provides no parameter descriptions. However, the description text explicitly explains each parameter: days_ahead (default 14, max 30), sector (filter by sector), min_flag_score (optional threshold). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'upcoming earnings with AI context — flag scores, verdicts, and risk factors per stock.' It distinguishes from siblings like get_earnings_calendar by emphasizing the AI pipeline integration to surface noteworthy events. Specific verb 'get' and resource 'earnings intelligence' are well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Pro tier only — AI pipeline cost attached' but does not explicitly contrast with alternatives like get_earnings_calendar or get_screener. It implies usage for AI-enhanced earnings screening but lacks clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_assessmentGet Market AssessmentARead-onlyIdempotentInspect
Combined AI market assessment: macro regime + market outlook in a single call. Produced every ~4 hours by the market intelligence pipeline.
Two distinct perspectives returned together:
REGIME (RISK_OFF/CAUTIOUS/NEUTRAL/AGGRESSIVE): answers "how much equity risk to take" → use for position sizing and asset allocation decisions
OUTLOOK (BULLISH/NEUTRAL/BEARISH): answers "which direction and sectors to trade" → use for sector preference and directional bias
Both share the same pipeline run so they are always in sync.
history_count: include last N prior assessments for each (0-3, default 0)
regime_*: risk posture fields — regime, regime_bias, regime_confidence, regime_rationale, key_risks, watch_for, vix_at_assessment, regime_updated_at
indicators.macro_data: FRED macro data (yield curve, Fed funds, cpi_index, unemployment, M2)
indicators.volatility_term_structure: VIX spot/3M/6M term structure + contango signal
indicators.market_sentiment: CNN Fear & Greed value and label
market_context: price/RSI/SMA200/perf snapshot of SPY/QQQ/IWM/TLT/GLD/VIX/TNX + sectors NOTE: point-in-time snapshot recorded when AI ran — not live prices (use get_market_pulse for live)
outlook_*: directional fields — outlook, outlook_conviction, equity_view, preferred_sectors, avoided_sectors, catalyst, outlook_key_risk, outlook_rationale, outlook_updated_at
Pro tier only — AI pipeline cost attached. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| history_count | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds: produced every ~4 hours by pipeline, point-in-time snapshot (not live), AI pipeline cost. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary first, then two perspectives, then detailed field lists. Some verbosity in listing all fields, but each adds context. Front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has high complexity with two output components; output schema exists (not shown) so description needn't detail every field. Provides overview of field groups (regime_*, indicators.*, etc.) and notes tier restriction. Covers key aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter history_count explained with range (0-3) and default, adding constraint beyond schema type. Schema coverage 0% but description fully covers the param. No other params to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a combined market assessment returning regime and outlook, with specific verbs ('Get') and resource ('Market Assessment'). Clearly distinguishes from sibling get_market_pulse by noting point-in-time vs live data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use each perspective: regime for position sizing, outlook for direction. Notes this is Pro tier only and not financial advice. Contrasts with get_market_pulse for live prices. Does not list alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_moversGet Market MoversARead-onlyIdempotentInspect
Top market movers from the Stocklake universe — gainers, losers, most active.
category: "gainers" | "losers" | "most_active" | "all" (default "all" = all 3 categories)
limit: results per category (default 10, max 20)
min_market_cap_b: filter to stocks above this market cap in billions (e.g. 1.0 = $1B+)
Returns per stock: symbol, name, sector, price, change_pct, volume, rsi, market_cap Available to all tiers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | No | all | |
| min_market_cap_b | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds behavioral context: returns per-stock fields, default/max limits, and category filtering. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear structure: a topic sentence, bulleted parameter list, and a line for return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional params) and presence of an output schema (with return fields listed), the description is complete. It covers all necessary information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries full burden. It explains each parameter: category options, limit default and max, min_market_cap_b filter. Also lists return fields, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns top market movers (gainers, losers, most active) from the Stocklake universe, distinguishing its purpose from siblings like get_market_pulse or get_screener.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over siblings or provide exclusion criteria. It mentions 'Available to all tiers' but lacks guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_pulseGet Market PulseARead-onlyIdempotentInspect
Live market health snapshot in a single call. Aggregates key market indicators without requiring multiple tool calls. No AI cost — reads live data directly from the market data feed.
Returns:
vix: VIX level and change_pct (from live stocks data)
fear_greed: value (0-100) and label (e.g. "neutral", "greed", "fear")
breadth: market-wide RSI distribution — oversold_pct, overbought_pct, neutral_pct, universe_size
indices: SPY, QQQ, IWM prices + RSI + 1-week performance
bonds: TLT (long-duration bonds), GLD (gold)
updated_at: when the breadth/fear_greed snapshot was last recorded Available to all tiers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states the tool reads live data directly from the market data feed and has no AI cost. Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description aligns with these, providing additional operational details such as data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a concise summary, then benefits, and a clear bulleted list of outputs. It is front-loaded with the key value proposition. While the list is somewhat lengthy, it is necessary for a zero-parameter tool to explain outputs. Could be slightly more concise but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and annotations cover safety, the description fully explains what the tool returns, its data sources, and its real-time nature. It is complete for an agent to understand when and how to use it, especially with the detailed output list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter description is needed. The description compensates by detailing the output structure, adding value beyond the empty schema. It lists all returned fields with explanations, which is helpful for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'live market health snapshot' and enumerates the specific indicators returned (vix, fear_greed, breadth, indices, bonds, updated_at). It distinguishes itself from siblings by highlighting aggregation of multiple indicators into a single call, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool aggregates key indicators without requiring multiple calls and reads live data with no AI cost, giving clear context for when to use it. However, it does not explicitly state when not to use it or compare it to alternatives like get_market_assessment or get_technical_signals, which could offer more detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_news_feedGet Market News FeedARead-onlyIdempotentInspect
Top AI-flagged news across all tracked stocks — the market-wide news briefing. Unlike get_stock_news (per-symbol), this scans the entire universe and returns the most notable articles ranked by AI flag score, newest first within each score tier.
Use this for:
Morning briefing: "what happened in the market this week?"
Catalyst scanning: "what news is driving moves right now?"
Event monitoring: "which stocks have high-impact news today?"
min_flag_score: minimum AI flag score (default 8, min 5, max 10) 8 = notable · 9 = high-impact · 10 = exceptional
days: look-back window in days (default 3, max 10)
limit: max articles returned (default 10, max 25)
Per article: symbol, title, published_at, ai_sentiment, ai_flag_score (0-10), ai_summary (full text), ai_confidence (0-10)
Pro tier only — AI pipeline cost attached. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| min_flag_score | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it's Pro tier only, has AI pipeline cost, and is for informational purposes. Also explains ranking by AI flag score and ordering. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bulleted use cases and parameter details. Every sentence adds value, no redundancy. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: purpose, parameters, return fields, cost, and disclaimer. Output schema exists, so return structure is further defined. Minor gap: no mention of pagination beyond limit, but max limit is stated. Overall complete for expected use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description fully documents each parameter: min_flag_score with defined thresholds (8,9,10), days and limit with defaults and max values. Also lists return fields per article, compensating for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns top AI-flagged news across all stocks, using specific verb 'get' and resource 'news feed'. Explicitly distinguishes from sibling tool get_stock_news by noting per-symbol vs market-wide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (morning briefing, catalyst scanning, event monitoring) and contrasts with get_stock_news. Gives clear guidance on when to use this tool vs the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_screenerScreen StocksARead-onlyIdempotentInspect
Power screener — filter stocks by technicals, fundamentals, and AI signals. More capable than search_stocks: exact RSI bounds, MACD/SMA filters, presets, and AI fields.
Parameters:
sector: e.g. "Technology", "Healthcare", "Financial Services"
min_rsi / max_rsi: exact RSI bounds (e.g. min_rsi=30, max_rsi=50 = post-oversold recovery zone)
sma_trend: "above_200" (price above 200-day MA) | "below_200"
macd_signal: "bullish" (MACD line above signal) | "bearish"
min_perf_1d / max_perf_1d: 1-day performance % (e.g. min_perf_1d=2.0 = up 2%+ today)
min_market_cap_b / max_market_cap_b: market cap in billions
max_pe_forward: maximum forward P/E (e.g. 20 = value screen)
min_flag_score: minimum AI flag score 0-10 (pro tier only — silently ignored for free)
preset: "oversold" | "overbought" | "momentum" | "high_conviction" (pro only) oversold = RSI≤35 + above SMA200 · overbought = RSI≥65 momentum = RSI 50-70, above SMA200, up 0.5%+ today · high_conviction = flag_score≥7
sort_by: "market_cap" | "rsi" | "perf_1d" | "analyst_rating" | "flag_score" (pro)
sort_dir: "asc" | "desc" (default "desc")
limit: 1–50 (default 20)
Pro tier: adds flag_score + ai_verdict to every result row, enables min_flag_score filter and high_conviction preset. All other filters available to all tiers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| preset | No | ||
| sector | No | ||
| max_rsi | No | ||
| min_rsi | No | ||
| sort_by | No | market_cap | |
| sort_dir | No | desc | |
| sma_trend | No | ||
| macd_signal | No | ||
| max_perf_1d | No | ||
| min_perf_1d | No | ||
| max_pe_forward | No | ||
| min_flag_score | No | ||
| max_market_cap_b | No | ||
| min_market_cap_b | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context, such as the silent ignoring of min_flag_score and high_conviction preset for free-tier users, and the addition of fields for pro tier. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for parameters and pro tier info, but it is verbose and could be more concise. Some sentences repeat information or are longer than necessary, reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 undocumented parameters, the description covers nearly all parameters with examples and allowed values, and explains pro-tier behavior. While output schema exists and is not described, the description is sufficiently complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by providing detailed semantics for each parameter: acceptable values, examples, defaults, and even preset definitions. This adds significant meaning beyond the basic schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens stocks by technicals, fundamentals, and AI signals. It distinguishes itself from the sibling search_stocks by explicitly listing advanced capabilities like exact RSI bounds, MACD/SMA filters, presets, and AI fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool over search_stocks, and details parameter usage with examples. However, it does not explicitly state when not to use it or mention other alternatives like get_stocks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sector_intelligenceGet Sector IntelligenceARead-onlyIdempotentInspect
AI-assessed sector intelligence: signal, cycle stage, rotation signal, drivers, alerts, and computed statistics per sector (RSI distribution, breadth, performance 1W/1M, top/bottom movers, historical percentiles). Pass a sector name for a single sector, or omit the parameter (or pass None) to get the latest assessment for all 11 sectors.
Refreshed every ~4 hours by the market intelligence pipeline. Available to pro tier only (AI pipeline costs). For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds that the data refreshes every ~4 hours, is from an AI pipeline with costs, and includes a disclaimer. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 70 words) with clear structure: first paragraph defines outputs, second explains parameter usage, third adds behavioral and legal context. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one optional parameter) and presence of an output schema, the description covers purpose, usage, underlying behavior, and disclaimers. It is complete 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the parameter fully: pass a sector name for single sector, omit for all 11. This provides complete semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'AI-assessed sector intelligence' and lists specific outputs. It differentiates from siblings by focusing on sector-specific computed statistics and mentions the single-sector vs all-sectors usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to pass a sector name vs omit or pass None. It also mentions refresh rate and pro tier availability. However, it does not provide explicit when-not-to-use or alternatives among siblings like get_sector_rotation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sector_rotationGet Sector RotationARead-onlyIdempotentInspect
All 11 market sectors in one call — signals, breadth, and momentum for rotation analysis. Where get_sector_intelligence gives deep analysis for one sector, this gives the rotation picture across all sectors simultaneously.
Use for: identifying sector rotation, finding leading vs lagging sectors, spotting breadth divergences, allocating capital across sectors.
Returns per sector (sorted by signal strength, LEADING first):
signal: LEADING | STRONG | NEUTRAL | WEAK | LAGGING
confidence: 0-10
alert: notable condition (narrow breadth, extreme RSI, etc.)
avg_rsi: sector-average RSI
sma200_breadth_pct: % of stocks in sector above their 200-day MA
oversold_pct / overbought_pct: RSI distribution extremes
perf_1w_pct / perf_1m_pct: average sector performance
updated_at: when this sector was last assessed by the AI pipeline
history_count: include last N prior signal states per sector (0-3, default 0) Pro tier only — AI-enriched sector signals. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| history_count | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, such as the sorted output by signal strength, the history_count parameter details, Pro tier restriction, and disclaimer. It aligns with annotations (readOnlyHint, idempotentHint) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections, but it is slightly verbose. Every sentence serves a purpose, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (though not shown) and the detailed description of return fields, parameter, usage, and behavioral notes, the description is complete and provides all necessary context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains the only parameter 'history_count' with its range (0-3) and default (0), adding meaning beyond the input schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns all 11 market sectors for rotation analysis, with a specific verb ('get') and resource ('sector rotation'). It distinguishes from the sibling 'get_sector_intelligence' which provides deep analysis for one sector, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use this tool ('Use for: identifying sector rotation...') and contrasts it with the sibling tool 'get_sector_intelligence', providing clear guidance on when to use this vs the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sentiment_profileGet Sentiment ProfileARead-onlyIdempotentInspect
Get AI-synthesized insider + institutional sentiment for a stock. Returns combined signal (BULLISH/BEARISH/NEUTRAL etc.), flag_score (8+=notable), confidence, per-source breakdown, and a human-readable summary. Data covers insider transactions (SEC Form 4) and institutional holdings. Pro tier only — AI pipeline cost attached. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds value by stating it's AI-synthesized, covers insider transactions and institutional holdings, and includes a disclaimer ('Not financial advice'). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose, then outputs, then data sources, then caveats. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema (not shown) likely covering return fields, the description explains the return structure, data sources, tier, and cost. For a single-parameter read-only tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter 'symbol' with 0% description coverage. The description clarifies 'for a stock', meaning symbol is a stock ticker. This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets AI-synthesized insider + institutional sentiment for a stock. It lists the return values (combined signal, flag_score, confidence, per-source breakdown, summary). This distinguishes it from siblings like get_stock or get_stock_ai_summary which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Pro tier only' and 'AI pipeline cost attached', which gives context on when to use (pro tier) and cost implications. It does not explicitly state when not to use or alternatives, but the context is clear enough for an agent to decide it's for sentiment analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stockGet StockARead-onlyIdempotentInspect
Price, fundamentals, technical indicators, and company profile for a stock. Returns all data needed to understand a stock in a single call.
Key fields:
price, change_pct, prev_close, week52_high/low, volume, avg_volume
market_cap, enterprise_value, beta
pe_trailing, pe_forward, price_to_book, dividend_yield, dividend_rate
debt_to_equity, profit_margins, return_on_equity, free_cashflow
revenue_growth, earnings_growth, revenue_ttm, gross_profit_ttm
analyst_rating: "strong_buy"|"buy"|"hold"|"sell"|"strong_sell" (analyst consensus)
analyst_rating_score: 1.0–5.0 mean analyst recommendation (1=strong_buy, 5=strong_sell)
analyst_target: mean analyst price target
analyst_count: number of analyst opinions
indicators: RSI, MACD, Bollinger Bands, SMA20/SMA200, EMA20/EMA200, ATR, ma_50, ma_200
description: company business description
website, employees, officers (top 5: name, title, total_pay)
updated_at: last data sync timestamp Available to all tiers.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe and idempotent. The description adds contextual value by noting 'Available to all tiers' and providing a detailed field list including 'updated_at' for freshness. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence and bullet-pointed fields. It is somewhat lengthy but every sentence adds value (e.g., field list, availability). Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description does not need to detail return values, but it provides a helpful list of key fields. It covers the main functionality, availability, and data freshness. Minor omissions like error handling or invalid symbol behavior, but overall complete for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'symbol' has no description in the input schema (0% coverage). The main description does not explain the parameter format (e.g., ticker symbol) beyond the schema. For such low coverage, the description should compensate, but it does not. However, the parameter name and tool context make it somewhat obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns price, fundamentals, technical indicators, and company profile for a stock. It provides a comprehensive list of key fields, making the purpose clear. The tool name 'get_stock' is distinct from siblings like 'get_stock_history' or 'get_stock_rating'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is a comprehensive one-stop call ('Returns all data needed to understand a stock in a single call'), but does not explicitly state when to use this versus more specific sibling tools like 'get_stock_history' or 'get_stock_rating'. Lacks direct guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_ai_summaryGet Stock AI SummaryARead-onlyIdempotentInspect
AI research summary for a stock — verdict, confidence, key points, and risk factors. Generated by the Stocklake AI pipeline (stock_ai_summary.py) on a nightly refresh cycle.
Returns:
verdict: "bullish" | "bearish" | "neutral"
confidence: 0-10 (how confident the AI is in its assessment)
flag_score: 0-10 (how notable/interesting this stock is right now — 8+ = worth attention)
summary: 2-4 sentence AI narrative
key_points: list of 3-5 bullish/neutral observations
risks: list of 2-3 specific risk factors
price_at_generation: stock price when the summary was generated
generated_at: UTC timestamp of last generation
Pro tier only — AI pipeline cost attached. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds beyond: nightly refresh cycle, static data (generated once per night), cost attached, and disclaimer. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points listing return fields. Every sentence adds value. Slightly long due to detailed return spec, but no fluff. Could be slightly shorter but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: what it returns (verdict, confidence, etc.), pipeline, refresh schedule, tier, cost, disclaimer. Given output schema exists, description still provides full context. Complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'symbol' is self-explanatory; description doesn't elaborate further. With 0% schema description coverage, the description could have added format or examples, but the parameter's meaning is obvious from its name and context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns an AI research summary for a stock, including verdict, confidence, key points, and risk factors. The verb 'Get' and resource 'Stock AI Summary' are explicit. It distinguishes from siblings like get_stock (basic info) and get_stock_rating (rating-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'Pro tier only — AI pipeline cost attached,' giving a usage constraint, but does not explicitly tell when to use vs. alternatives or when not to use. Lacks comparison to siblings like get_stock_rating or get_technical_signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_historyGet Stock Price HistoryARead-onlyIdempotentInspect
Daily OHLCV price history for a stock.
days: number of trading days to return (default 90, max 365)
Returns: { symbol, days, count, history[] }
Per bar: date, open, high, low, close, volume
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the return shape ({ symbol, days, count, history[] }) and per-bar fields, as well as constraints on days (default 90, max 365). This goes beyond annotations to give clear behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two lines of text plus bullet points. It front-loads the purpose and uses a clear structure. Every sentence adds value; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema (indicated by context), the description sufficiently covers return format, parameters, and defaults. It does not mention error handling or data currency, but given the tool's simplicity, it is largely complete. A minor gap: no note on calendar vs. trading days.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must define parameters. It explains 'days' as number of trading days with default and max, and implies 'symbol' is a stock ticker. The return structure is also detailed, compensating well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Daily OHLCV price history for a stock,' using a specific verb and resource. It distinguishes from sibling tools like get_stock (which likely returns current data) and get_technical_signals (which are derived).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs. alternatives. With 20 sibling tools, the agent would benefit from context like 'Use this for raw price data; for technical indicators use get_technical_signals.' Absence of such guidance lowers the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_newsGet Stock NewsARead-onlyIdempotentInspect
AI-analysed news for a stock, newest first. Only returns articles processed by our AI pipeline (sentiment, flag score, summary).
days: look-back window in days (default 30, max 30)
limit: max articles returned (default 10, max 10)
status: "ok" = articles returned | "empty" = no news in window
Per article: title, published_at, ai_sentiment, ai_flag_score (0-10), ai_summary (full text), ai_confidence (0-10) Pro tier only — AI pipeline cost attached. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, non-destructive. The description adds that it returns only AI-processed articles, newest first, includes cost and informational disclaimer, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then constraints, parameters, output fields, and notes. Every sentence adds unique value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description still covers purpose, parameters, output structure, and usage notes. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains days/default/max, limit/default/max, and status response field, fully compensating for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'AI-analysed news for a stock, newest first', specifying the resource and distinguishing it from sibling tools like get_news_feed (general news) and get_stock_ai_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context: Pro tier only with AI pipeline cost, and explains parameter defaults and limits. However, it does not explicitly contrast with alternatives like get_news_feed for raw news.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_ratingGet Stock RatingARead-onlyIdempotentInspect
Technical rating (0–10) for a stock with per-indicator breakdown. Uses RSI, MACD, Bollinger Bands, and SMA50/SMA200 trend analysis.
rating: 0–10 composite score
direction: BULLISH (≥6) | NEUTRAL (4–6) | BEARISH (≤4)
signals: per-indicator breakdown with verdict and strength Available to all tiers (guest, free, pro) — computed from stored indicators, no AI cost.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: specific indicators used (RSI, MACD, Bollinger Bands) and output format (rating, direction, signals). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three informative sentences covering purpose, method, and availability. No wasted words, front-loaded with key output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers rating scale, direction interpretation, signal breakdown, and tier availability. Output schema exists, so return values need not be detailed further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description does not elaborate on the 'symbol' parameter beyond listing it as required. However, the parameter is simple and commonly understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a technical rating (0–10) with per-indicator breakdown, distinguishing it from siblings like get_technical_signals or get_stock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions availability to all tiers and no AI cost, guiding agent to use it freely. Does not give explicit when-not or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stocksGet Multiple StocksARead-onlyIdempotentInspect
Batch stock data for up to 50 symbols in a single call. Returns a dict keyed by symbol. Missing symbols are omitted from the result. Each symbol in the batch counts as one call toward the daily limit. Available to all tiers.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral details beyond annotations: batch limit of 50, omission of missing symbols, per-symbol counting toward daily limit, and availability to all tiers. Annotations already mark it as read-only and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with no waste. Front-loaded with the core purpose and constraint, then adds necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values are covered elsewhere. Description covers batch limit, missing handling, counting policy, and accessibility. Missing order preservation or error handling, but these are minor for a simple batch read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions the constraint of up to 50 symbols and that missing symbols are omitted, adding meaning to the symbols parameter. However, it does not explicitly name the parameter or describe required/optional nature, which is needed given low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch stock data' with a verb and resource, and distinguishes itself from the sibling get_stock tool by indicating it handles multiple symbols in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use: for batch data up to 50 symbols, and provides context on missing symbols and call counting. It implicitly suggests alternatives (use get_stock for single symbol) but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_symbol_contextGet Symbol ContextARead-onlyIdempotentInspect
Full research context for a symbol in one call — fundamentals, AI summary, news, sentiment, and discovery status. Replaces 5 separate calls: get_stock + get_stock_ai_summary + get_stock_news
get_sentiment_profile + get_discovery_ideas (for one symbol).
Returns:
stock: price, name, sector, rsi, pe_forward, market_cap, 52-week range, analyst data
ai_summary: verdict, confidence, flag_score, full summary, key_points, risks
news: last 3 high-relevance articles (title, published_at, ai_sentiment, ai_flag_score, ai_summary)
sentiment: signal, confidence, insider_trend (buying/selling/neutral), institutional_pct
discovery: active discovery idea for this symbol, if any (direction, conviction, rationale)
All data is pre-computed by the Stocklake AI pipeline — no live AI calls on request. Pro tier only. For informational purposes only. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe read behavior. The description adds valuable context: data is pre-computed (no live AI calls), and it includes a disclaimer ('Not financial advice'). This goes beyond annotations and fully discloses operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the core purpose, followed by a line indicating it replaces multiple calls, and then a bullet list of return fields. Every sentence earns its place, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple data types) and presence of an output schema, the description provides a thorough list of return sections. It also mentions Pro tier and a disclaimer. However, it lacks information about error conditions or symbol validation, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (symbol) with 0% schema description coverage. The description does not define 'symbol' explicitly, but context implies it's a stock ticker. While adequate, it does not add significant meaning beyond what is assumed, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'full research context for a symbol' and enumerates the included data types (fundamentals, AI summary, news, sentiment, discovery status). It explicitly distinguishes from siblings by noting it replaces 5 separate calls, making the tool's purpose very specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this tool replaces 5 separate calls, giving strong guidance on when to use it (for comprehensive context). However, it does not explicitly state when NOT to use it or provide direct comparisons with siblings beyond the replacement list, slightly limiting guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_technical_signalsGet Technical SignalsARead-onlyIdempotentInspect
Structured technical signal summary — agent-ready labeled outputs for a stock. Unlike get_stock_rating (composite score + nested breakdown), this returns flat labeled signals optimized for programmatic consumption without parsing raw numbers.
Returns:
overall: BULLISH | NEUTRAL | BEARISH (composite)
rsi: value + signal label (oversold / recovering / neutral / approaching_overbought / overbought)
macd: signal (bullish/bearish), histogram, strength (strong/moderate/weak)
bollinger: position (below_lower / lower_half / upper_half / above_upper), bandwidth_pct
sma200: trend (above/below), gap_pct (distance from 200-day MA as %)
sma50: trend (above/below), gap_pct
williams_r: value (0 to -100) + signal (overbought >-20 / neutral / oversold <-80)
ultimate_osc: value (0-100) + signal (overbought >70 / neutral / oversold <30)
vix_fix: value + percentile (vs trailing year) + signal (elevated_fear / calm) — fear gauge
williams_ad: trend (rising/falling/flat) + divergence (bullish/bearish/None) — flow direction Williams %R + Ultimate Oscillator are blended into the overall composite. Available to all tiers.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description need not repeat that. It adds context about the output format and composite blending, which is helpful. No contradictions. Transparency is good, but no additional behavioral traits beyond annotations are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured with a clear opening and a bulleted list of return fields. Every sentence adds value, but could be slightly more concise. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 presence of an output schema, the description exhaustively details all return fields and their formats, as well as the composite calculation. No gaps in context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (symbol) has no description in either the input schema or the tool description. Schema description coverage is 0%, so the description must compensate but does not. The parameter is simple, but the lack of any explanation reduces semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a structured technical signal summary for a stock, and explicitly contrasts with a sibling tool (get_stock_rating) by noting the different output format (flat labeled signals vs composite score). The verb 'Get' and resource 'technical signals' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing programmatic technical signals and mentions availability to all tiers. However, it does not explicitly state when to use vs. not use, nor list alternative tools beyond the single comparison. Slightly above average but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_stocksSearch StocksARead-onlyIdempotentInspect
Filter and rank stocks from the Stocklake universe.
sector: e.g. "Technology", "Healthcare", "Financial Services"
country: e.g. "United States", "Germany"
rsi_signal: "oversold" (<30) | "overbought" (>70) | "neutral" (30–70)
analyst_rating: "strong_buy" | "buy" | "hold" | "sell" | "strong_sell"
min_volume: minimum daily volume (e.g. 1000000)
min_market_cap_b: minimum market cap in billions (e.g. 10 = $10B+)
max_market_cap_b: maximum market cap in billions (e.g. 2 = small-cap only up to $2B)
max_pe_forward: maximum forward P/E ratio filter (e.g. 20 = value screens)
sort_by: "change_pct" | "volume" | "market_cap" | "rating" | "rsi_asc" (oversold first) | "rsi_desc" (overbought first)
limit: max 50 (default 20)
Returns: { count, filters, results[] } — each result includes symbol, name, sector, price, change_pct, volume, market_cap, rsi, pe_forward, analyst_rating, rating (0–10), direction Available to all tiers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sector | No | ||
| country | No | ||
| sort_by | No | change_pct | |
| min_volume | No | ||
| rsi_signal | No | ||
| analyst_rating | No | ||
| max_pe_forward | No | ||
| max_market_cap_b | No | ||
| min_market_cap_b | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds useful context: availability to all tiers, return structure, and parameter constraints (e.g., limit max 50). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a paragraph with bullet-style parameter listings. Every sentence adds value, though some redundancy exists (e.g., 'Available to all tiers' is brief but useful). Could be slightly more structured, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 0% schema coverage, and an output schema, the description covers all needed context: parameter explanations, return structure outline, and filter options. It is comprehensive for a filtering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter with examples and acceptable values. E.g., rsi_signal enums, sort_by meanings, min/max market cap in billions. No parameter is left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool filters and ranks stocks from a specific universe (Stocklake). The verb 'search' combined with 'filter and rank' and parameter listing distinguishes it from sibling 'get_stocks' (likely retrieves by symbol) and 'get_screener' (possibly similar but not detailed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for screening stocks by various criteria. It provides parameter examples but does not explicitly state when to use this tool versus alternatives. However, the context is clear enough for an agent to infer its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!