AlphaAI News is a real-time, AI-enriched financial news server for AI agents and trading bots, providing filtered and scored news across stocks, ETFs, and crypto via MCP tools.
Search financial news (alphai_news_search): Full-text search with filters for tickers, category (14 buckets: earnings, M&A, regulation, crypto, etc.), date range, and minimum AI relevance score (1–10); supports pagination and story deduplication.
Ticker news feed (alphai_ticker_news): Latest news for a specific ticker, optionally including insider/SEC Form 4 trades and 13F ownership moves.
Trending stories (alphai_trending): Top stories from the last 48 hours ranked by AI relevance score.
Actionable breaking news (alphai_actionable_now): Decision-grade breaking news from recent hours (e.g. surprise earnings, M&A, trading halts), filtered by actionability and novelty scores.
Insider & ownership news (alphai_insider_news): SEC Form 4 insider trades and 13F institutional ownership moves, filterable by ticker and date range.
Two-ticker read-across (alphai_pair_analysis): News mentioning both tickers simultaneously, plus each ticker's own recent news for context.
Fetch single article (alphai_article): Full AI enrichment (ticker analysis, context, key entities) for a specific article by UID (no raw body due to copyright).
Discover supported tickers (alphai_tickers): Search and list supported US stocks, ETFs, crypto, and foreign listings, filterable by query prefix or sector.
Manage alert subscriptions (alphai_alerts_list/subscribe/unsubscribe): List, create, and remove personalized ticker news alerts with custom category filters and relevance thresholds (Basic/Pro tiers only).
Access is OAuth-based with a free tier (100 calls/day), Basic ($2.99/mo), and Pro ($9.99/mo) offering higher rate limits and larger page sizes.
Real-time, AI-enriched financial news for AI agents and trading bots — over the
Model Context Protocol. Hosted at mcp.alphai.io,
no install, OAuth (no API key to paste), free tier 100 calls/day.
Every story is enriched with per-ticker analysis, a category (14 buckets), and a 1–10 relevance score, so an agent can filter to what actually matters before spending a reasoning token.
This repo is the public home +
server.jsonmanifest of the hosted AlphaAI MCP server (the listing on Smithery, Glama, mcp.so, the MCP Registry and Awesome MCP Servers). The product is AlphaAI — a financial-news platform built for AI agents. There is nothing to self-host: to use it, just connect tohttps://mcp.alphai.io/mcp.
The server speaks Streamable HTTP at https://mcp.alphai.io/mcp. Add it to any
OAuth-capable MCP client. Claude Code:
claude mcp add --transport http alphai https://mcp.alphai.io/mcpConnecting opens a browser for OAuth 2.1 (DCR + PKCE) — a login, no key to copy-paste. ChatGPT, Claude Desktop / claude.ai, Cursor, VS Code, Windsurf and Gemini connect the same way. Or use the one-click listing on Smithery.
JSON config clients (Cline, Cursor and similar):
{
"mcpServers": {
"alphai": {
"type": "http",
"url": "https://mcp.alphai.io/mcp"
}
}
}Client | Config |
Claude Desktop / claude.ai | Settings → Connectors → Add custom connector → |
Cursor |
|
VS Code Copilot |
|
Generic | Streamable HTTP, URL |
Related MCP server: cryptopolitan-mcp
MCP Server URL: https://mcp.alphai.io/mcp
alphai_news_search - Full-text + filtered news search (query, tickers, category, dates, relevance)
alphai_ticker_news - Latest news for one ticker (optionally incl. insider)
alphai_trending - Biggest stories of the last 48h by relevance
alphai_actionable_now - Breaking, decision-grade news (actionability + novelty gate)
alphai_insider_news - SEC Form 4 insider trades + 13F ownership moves as news
alphai_pair_analysis - Two-ticker read-across (news naming both companies)
alphai_article - Fetch a single article by uid (adds a structured earnings read on SEC filings)
alphai_earnings - AlphaAI's filing-verified earnings reads per ticker, plus the next report date
alphai_calendar - Scheduled macro releases (CPI, FOMC, jobless claims) with times and the coverage that followed
alphai_macro - Macro-economy feed (prints, central banks, rates, FX, commodities)
alphai_tickers - Discover supported tickers (US stocks, ETFs, crypto & foreign listings, incl. each one's next_report_date)
alphai_alerts_list / alphai_alerts_subscribe / alphai_alerts_unsubscribe - Manage your own ticker alert subscriptions (Basic/Pro)
All tools are read-only except the alphai_alerts_* writes, which only ever touch the
caller's own subscriptions. Full schemas, params and defaults are advertised by the server
(annotations included) and documented at alphai.io/mcp.
Free | Basic | Pro | |
Price | $0 (no card) | $2.99/mo | $9.99/mo |
Rate limit — burst | 20 / min | 60 / min | 150 / min |
Rate limit — daily | 100 / day | 10,000 / day | 100,000 / day |
Alert tools | — | ✓ | ✓ |
Page size | 10 | 10 | up to 50 (bulk) |
OAuth 2.1 with Dynamic Client Registration (RFC 7591)
and PKCE per the
MCP authorization spec.
Compatible clients discover the OAuth metadata automatically — no manual API key setup.
Tool discovery (tools/list) is open; calling a tool requires the OAuth login.
Drop-in skills that drive these tools (stock brief, market pulse, insider radar, peer read-across, manage alerts): makeev/alphai-claude-skills.
Playground & docs — https://alphai.io/mcp
REST API & SDKs (Python + TypeScript) — https://alphai.io/developers
Smithery listing — https://smithery.ai/servers/mihail-makeev/alphai-news
Glama connector — https://glama.ai/mcp/connectors/io.github.makeev/alphai-mcp
MCP Registry — io.github.makeev/alphai-mcp
Changelog — https://alphai.io/changelog
This is a hosted server — to use it, connect to https://mcp.alphai.io/mcp; there
is nothing to self-host. This repo is the catalog home + server.json manifest.
News, not advice. The tools summarize reporting; they don't give buy/sell calls.
raw_text (full article bodies) is never served — copyright. Responses carry titles,
AI summaries, per-ticker analysis, categories and relevance scores.
MIT licensed. Built by AlphaAI.
Breaking, decision-grade news from the last few hours. The primary filter is the enricher's actionability score, and the gate is strict: by default only actionability='high' (a concrete trading decision to act on TODAY — fresh guidance cut, halted trading, breaking M&A, surprise print) qualifies. Big-but-not-urgent stories scored 'medium' (shape a position over days/weeks) never appear at the default floor no matter how high their novelty — pass min_actionability='medium' to include them, or use alphai_trending / alphai_ticker_news for the broader tape. An empty list outside US market hours (nights, weekends) is expected — it means no high-actionability prints in the window, not an error; widen hours or min_actionability before concluding nothing happened. min_novelty is a secondary threshold that drops post-event recaps of already-public stories. Ordered novelty-first; syndicated reprints collapsed by story (dedupe=false to keep all).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Stories. 10 Basic / 50 Pro (tools.bulk). | |
| hours | No | Look-back window in hours; default 6. | |
| min_novelty | No | Min information_novelty 1-10; default 7. | |
| min_actionability | No | Actionability floor. 'high' (default) = only act-today items; 'medium' also includes stories that shape a position over days/weeks. | high |
| dedupe | No | Collapse syndicated reprints by story (default true). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, openWorldHint. The description adds extensive behavioral context: the actionability scoring scale (high vs medium), expected empty lists during off-hours, deduplication behavior, and novelty-first 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?
The description is a single dense paragraph that is front-loaded with the core purpose. It efficiently covers key details but could benefit from breakpoints or bullet lists for readability. No unnecessary fluff.
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 complexity (5 parameters, semantic filters, market hours context, sibling differentiation) and the presence of an output schema, the description is remarkably complete. It addresses expected behaviors, edge cases, and alternative tools, enabling confident 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?
Schema description coverage is 100%, providing a baseline of 3. The description adds value by explaining how min_actionability interacts with the default floor, how min_novelty serves as a secondary threshold, and how dedupe collapses syndicated reprints. This goes beyond the schema's individual parameter 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 the tool provides 'breaking, decision-grade news from the last few hours' with specific actionability filtering. It uses a concrete verb-resource ('Actionable-now feed') and distinguishes itself from siblings like alphai_trending and alphai_ticker_news, which serve broader tape needs.
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 tells when to use this tool (for high-actionability, act-today news) and when not to (use alphai_trending or alphai_ticker_news for broader tape). It also explains expected empty results outside market hours and how to adjust parameters to include medium-actionability items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the caller's active ticker news-alert subscriptions, including per-subscription filters (category whitelist, minimum relevance score, delivery mode).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true. The description adds behavioral context about the returned fields (filters) without contradicting 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?
One clear, front-loaded sentence with no wasted words. Efficiently communicates the tool's function.
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 no parameters and an existing output schema, the description provides sufficient context about what is returned (subscriptions with filters). Complete for a list 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 input schema has 0 parameters, so the description need not add parameter details. Baseline score of 4 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 the verb 'List' and the resource 'active ticker news-alert subscriptions', including specific details about filters returned. It distinguishes from siblings like subscribe/unsubscribe.
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 implicitly indicates when to use (to list subscriptions) but lacks explicit guidance on when not to use or alternatives. Sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe the caller to ticker news alerts. Optional category_filter (e.g. ['earnings','insider']) restricts which categories trigger; min_relevance_score raises the threshold. This is a partial update: omitting either field on an existing subscription preserves its current value, and a brand-new subscription defaults min_relevance_score to 6. Raises tier_not_paid / unknown_ticker / limit_reached.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker to subscribe to (active symbol). | |
| category_filter | No | Categories that trigger alerts. | |
| min_relevance_score | No | Min relevance to alert on. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true (non-destructive, read-write). The description adds behavioral details: partial update preserves omitted fields, new subscription defaults min_relevance_score to 6, and error conditions. This 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?
Two sentences contain all essential information: action, optional params, behavior (partial updates, defaults), and errors. No fluff, front-loaded with the 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?
Given annotations and output schema, the description covers input behavior, defaults, and errors. It could mention that the output is a subscription object, but output schema likely handles that. Adequately complete for a subscription 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 100% with descriptions. The description adds value by clarifying usage (e.g., 'category_filter restricts which categories trigger', 'min_relevance_score raises the threshold') and explaining defaults and partial update 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?
The description clearly states the action ('subscribe the caller to ticker news alerts') and resource, differentiating from siblings like unsubscribe and list. It specifies optional filters, making the purpose precise.
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 optional parameters, partial update behavior, defaults, and possible errors (tier_not_paid, unknown_ticker, limit_reached), providing good guidance. However, it does not explicitly contrast with alternative tools like alphai_alerts_unsubscribe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Soft-disable the caller's news-alert subscription for the given ticker. Idempotent — returns {removed: false} if the alert was already inactive. Raises unknown_ticker for an unrecognized symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker to unsubscribe from. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructive and idempotent hints. The description adds context by stating 'Soft-disable', specifying the return value for already inactive alerts, and the unknown_ticker error. This goes beyond annotations by detailing exact behavior.
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 at two sentences, with no unnecessary words. Every sentence adds value: first defines action and idempotency, second covers error case.
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 (implied by the context signal) and strong annotations, the description covers key behaviors. The only minor gap is not explicitly stating the success return value beyond the idempotent case, but overall it is comprehensive.
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 100% with a parameter description 'Ticker to unsubscribe from.' The description does not add meaningful additional semantics beyond restating 'for the given ticker'. Baseline 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 the verb 'Soft-disable' and the resource 'the caller's news-alert subscription for the given ticker'. It distinguishes itself from siblings like alphai_alerts_subscribe by specifying the opposite action, and explains idempotency and error behavior.
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 when to use (to stop alerts for a ticker) and provides guidance on idempotency and error handling. However, it does not explicitly mention alternatives or when not to use, but the context is clear given the tool name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single article (with full enrichment: ticker analysis, context, key entities) by its uid. The full article body is intentionally not served (copyright) — this is the canonical single-article lookup, not a fuller view. Raises not_found for an unknown uid.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | The article uid from any feed response. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld), the description adds critical behavioral details: the copyright restriction on the full body and the not_found error for invalid uids. There is 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 two sentences with no waste. The first sentence front-loads the main purpose and enrichment, the second covers limitations and error behavior. Every sentence is essential.
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 one parameter and an output schema, the description explains what is returned (enriched fields) and what is not (full body), plus error handling. It is fully complete for an agent to use 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?
The single parameter 'uid' is fully described in the schema. The description adds 'from any feed response', which provides useful context beyond the schema's description. Since schema coverage is 100%, the baseline is 3, and the added context raises it to 4.
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 verb 'fetch' and the resource 'article', specifying the enrichment components. It distinguishes this tool from siblings like alphai_news_search by calling it the 'canonical single-article lookup' and noting the intentional absence of the full article body.
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 implicitly provides usage guidance by stating it is the canonical lookup and that the full body is not served due to copyright, hinting that other tools may be needed for full text. It also explicitly states the error behavior for unknown uids. However, it does not explicitly list when to use or not use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ownership-change news: SEC Form 4 insider trades (company officers, directors and 10% owners buying or selling their own stock) plus 13F institutional ownership moves (funds and foundations increasing or trimming stakes). Optionally filter by ticker and date range. Cursor-paginated; same shape as alphai_news_search. Roughly equivalent to alphai_news_search(category='insider'), exposed as a dedicated tool. Sets unknown_ticker=true when a ticker filter isn't a recognized active symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | Restrict to one ticker, e.g. 'AAPL'. | |
| from_date | No | On/after this ISO time (UTC if naive). | |
| to_date | No | On/before this ISO time (UTC if naive). | |
| min_relevance | No | Minimum AI relevance score, 1-10. | |
| page_size | No | Items/page. 10 Basic / 50 Pro (tools.bulk). | |
| cursor | No | Opaque cursor from a prior next_cursor. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world. Description adds cursor pagination, shape equivalence, and the unknown_ticker flag behavior, which are valuable 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?
Two concise sentences plus a note, all front-loaded with key information. No redundant text.
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 purpose, filtering, pagination, shape, equivalent tool, and a behavioral flag. With output schema present, description is fully complete for a news retrieval 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?
All 6 parameters are well-documented in the input schema with descriptions. The tool description adds minor context about unknown_ticker and cursor pagination shape, but does not significantly enhance parameter understanding 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?
Description clearly states the tool returns ownership-change news from SEC Form 4 and 13F filings, and distinguishes itself by noting equivalence to alphai_news_search(category='insider').
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 to use this tool for insider/ownership news with optional ticker and date filters, and mentions the dedicated tool alternative. Lacks explicit when-not-to-use 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.
Search AlphaAI's enriched financial news feed. Filter by free-text query (tokens are AND-matched across title and summary), ticker symbols, category, date range, and minimum relevance score (1-10). Results are paginated with an opaque cursor. Set collapse_stories=true to get one row per story instead of every syndicated reprint, with a sources_count corroboration signal.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text query; tokens AND-matched in title/summary. | |
| tickers | No | Restrict to news mentioning these tickers. | |
| category | No | Restrict to one news category. | |
| from_date | No | News on/after this ISO time (UTC if naive). | |
| to_date | No | News on/before this ISO time (UTC if naive). | |
| min_relevance | No | Minimum AI relevance score, 1-10. | |
| page_size | No | Items/page. 10 Basic / 50 Pro (tools.bulk). | |
| cursor | No | Opaque cursor from a prior next_cursor. | |
| collapse_stories | No | Collapse syndicated reprints to one representative per story and populate story_id/sources_count/sources (default false). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: pagination with opaque cursor, collapse_stories behavior, AND-matching of tokens, and the sources_count signal. It does not contradict annotations (readOnlyHint, idempotentHint).
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, each adding value without redundancy. It is front-loaded with the main purpose, then details filters, pagination, and collapse option. No unnecessary 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 complexity (9 parameters, output schema exists), the description covers all key aspects: filtering capabilities, pagination, collapse behavior, relevance score range. It mentions date format implicitly but clearly. No 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 100%, so the baseline is 3. The description summarizes parameter categories but does not add new details beyond what is already in the schema descriptions for each parameter. It does not provide additional syntax or format guidance.
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 verb 'Search' and the resource 'AlphaAI's enriched financial news feed', and lists comprehensive filtering options (free-text, tickers, category, date range, relevance). This distinguishes it from sibling tools like alphai_ticker_news or alphai_trending, which have more specific scopes.
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 general financial news search with rich filters. While it does not explicitly exclude alternatives, the sibling names and the tool's own filtering capabilities provide sufficient context for an AI agent to decide when to use this tool. A small improvement would be to add a sentence about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two tickers (e.g. NVDA and AMD). Returns news naming BOTH companies — where the cross-ticker read-across lives (a peer's print resetting the other's setup, a shared supplier/customer) — plus each ticker's own recent news for context. Any symbol that isn't a recognized active ticker is listed in unknown_tickers and contributes no rows.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker_a | Yes | First ticker, e.g. 'NVDA'. | |
| ticker_b | Yes | Second ticker, e.g. 'AMD'. | |
| min_relevance | No | Minimum AI relevance score, 1-10. | |
| limit | No | Max rows per list (both / each ticker). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds detail about the output structure (both-ticker news, individual news, unknown_tickers handling) and filtering by relevance and limit, providing useful behavioral 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?
The description is three sentences, front-loaded with purpose, and contains no unnecessary words. Every sentence adds value, making it concise and well-structured.
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 complexity (two-ticker comparison, cross-read, unknown tickers), the description covers the key behavioral aspects. An output schema exists for detailed return structure, and annotations cover safety. The description is complete for an AI agent to select and invoke the tool 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 100% with parameter descriptions. The tool description ties parameters to the tool's purpose, explaining how ticker_a and ticker_b are used, that min_relevance filters by AI relevance, and that limit controls rows per list. This adds semantic value beyond the 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 verb 'Compare' and the resource 'two tickers', specifying the output includes news naming both companies plus individual recent news. It distinguishes from siblings like alphai_ticker_news by emphasizing cross-ticker read-across.
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 when to use this tool (for cross-ticker read-across where a peer's print resets another's setup) and what it returns. It doesn't explicitly state when not to use it or mention alternatives, 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.
Latest news for a single ticker (e.g. 'AAPL'). Cursor-paginated; returns the same shape as alphai_news_search. Insider news (SEC Form 4 trades + 13F ownership moves) for the ticker is included by default — pass include_insider=false for a pure non-insider feed. Set collapse_stories=true to get one row per story instead of every syndicated reprint. Sets unknown_ticker=true when the symbol isn't a recognized active ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. 'AAPL'. | |
| include_insider | No | Include insider/13F ownership news; default true. | |
| page_size | No | Items/page. 10 Basic / 50 Pro (tools.bulk). | |
| cursor | No | Opaque cursor from a prior next_cursor. | |
| collapse_stories | No | Collapse syndicated reprints to one representative per story and populate story_id/sources_count/sources (default false). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, and openWorldHint. The description goes beyond these by detailing pagination (cursor-based), the inclusion of insider news by default with an option to exclude, the collapse_stories feature, and the setting of unknown_ticker for unrecognized symbols. This adds significant value for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise three-sentence paragraph. The first sentence states the core purpose. The second explains key options (include_insider, collapse_stories). The third mentions an important behavior (unknown_ticker). Every sentence is necessary and adds value, with no redundancy or fluff.
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 complexity (5 params, 1 required) and the presence of an output schema, the description adequately covers all important behaviors: pagination, insider inclusion, story collapsing, and error flag for unknown tickers. It even references alphai_news_search for output shape, providing a complete picture for an 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?
Schema description coverage is 100%, so baseline is 3. The description adds extra context: the ticker example, the default inclusion of insider news, the page size limits (10 basic/50 Pro), and the behavior of unknown_ticker (only mentioned in description, not in schema). This provides meaning beyond the 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 the tool provides 'Latest news for a single ticker', specifying the action (latest news) and resource (single ticker). It distinguishes itself from siblings like alphai_news_search (which likely covers multiple tickers or search queries) and alphai_insider_news (which is pure insider news) by highlighting the inclusion of insider news by default and the ability to get a non-insider feed.
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 when to use this tool: when you need the latest news for a specific ticker, optionally including or excluding insider news. It mentions cursor-pagination and states it returns the same shape as alphai_news_search, providing a reference for expected format. However, it does not explicitly state when not to use it or mention alternatives beyond implicit differentiation from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported stock and ETF tickers. Optionally filter by query (prefix on ticker, substring on name) or by sector.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Prefix match on ticker, substring on name. | |
| sector | No | Filter by sector (case-insensitive). | |
| limit | No | Max rows to return. | |
| offset | No | Pagination offset. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds no further behavioral information (e.g., about rate limits or result structure). It does not contradict 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?
Two concise sentences with no redundant information. Front-loaded with the core purpose, then filter options.
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 output schema, full parametric documentation in schema, and comprehensive annotations, the description is complete enough for an agent to invoke the tool 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 description coverage is 100%, so the baseline is 3. The description restates parameter behavior (prefix/substring search) that is already in the schema, adding no new meaning.
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 'List supported stock and ETF tickers' with optional filters, matching the title. This distinctively identifies it from sibling tools like alphai_ticker_news or alphai_news_search, which handle news.
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 context for when to use: to list tickers with optional filtering by query or sector. It does not explicitly exclude alternative tools, but the purpose is sufficiently clear given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top news from the last 48h ranked by AI-assigned relevance. Use this when the user asks 'what's moving' / 'what's the big story'. Lower min_relevance to surface weaker movers. Syndicated reprints of one story are collapsed to a single representative by default (dedupe=false to keep all).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Stories. 10 Basic / 50 Pro (tools.bulk). | |
| min_relevance | No | Min AI relevance 1-10; default 8. | |
| dedupe | No | Collapse syndicated reprints by story (default true). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe, idempotent read. Description adds: deduplication behavior (collapse syndicated reprints by default, dedupe=false to keep all) and the 48h time window. Adds value 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?
Three concise sentences: purpose, usage guidance, parameter tips. No fluff, each sentence earns its place.
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?
Complexity is low (3 optional params with defaults, output schema exists). Description covers purpose, usage, and parameter behavior completely. No 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 100%. Description adds usage guidance: 'Lower min_relevance to surface weaker movers' and explains dedupe parameter behavior. Adds value 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?
Clearly states it returns top news from the last 48h ranked by AI relevance. Distinguishes from siblings like alphai_news_search and alphai_ticker_news, which are search/ticker-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?
Explicitly says to use when user asks 'what's moving' or 'what's the big story', and advises on tuning min_relevance. No explicit when-not, but context with sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have clear distinct purposes, but alphai_actionable_now and alphai_trending both return recent news with different filters, potentially causing confusion. alphai_ticker_news and alphai_news_search also overlap when filtered by ticker, though descriptions help differentiate.
All tools follow a consistent 'alphai_' prefix followed by descriptive snake_case names (e.g., alphai_actionable_now, alphai_alerts_subscribe). No mixing of conventions.
With 11 tools, the server covers the key aspects of financial news (search, alerts, trending, ticker-specific, pair analysis, insider news) without being overwhelming. Each tool serves a distinct function within a well-scoped domain.
The tool surface covers core news operations (search, retrieval, alerts, trending, insider news) but lacks explicit category-only browsing or sector-filtered news. However, the search tool with filters and dedicated tools for insider/trending effectively mitigate major gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
Real-time news with bias scoring, live market data, and AI-powered options pricing
Korean + US market data for AI agents: DART, Korean prices/screeners, SEC EDGAR, 13F. Free tier.
Real-time corroborated news events + 5-year archive, for agents. Free tier, no key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/makeev/alphai-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
