AlphaAI
Server Details
AI-enriched financial news for AI agents & trading bots: search, trending, insider, scored 1-10.
- 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.5/5 across 13 of 13 tools scored.
Most tools have distinct purposes, but there is overlap between alphai_news_search and search (both do free-text search) and between alphai_article and fetch (both retrieve by ID). The descriptions attempt to differentiate them, but an agent might still confuse them.
The majority of tools follow the alphai_ prefix with snake_case naming, but fetch and search deviate by lacking the prefix and using simple names. This inconsistency could cause confusion about tool grouping.
13 tools cover the domain of financial news analysis, alert management, and ticker lookup without being excessive. Each tool serves a clear function, and the count is well-scoped for the server's purpose.
The tool set covers core news retrieval (multiple filters), alerts (create/list/disable), ticker lookup, and pair analysis. Minor gaps include no hard delete for alerts and no explicit category listing, but these are not critical for most use cases.
Available Tools
13 toolsalphai_actionable_nowActionable-now feedARead-onlyIdempotentInspect
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 time-sensitive development — 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. The time window is over each article's PUBLICATION time, not the underlying event's date, so a fresh pick-up of an older event can appear; min_novelty (not the window) is what drops post-event recaps of already-public stories. Ordered novelty-first; syndicated reprints collapsed by story (dedupe=false to keep all). Each item carries the full AI analysis inline — no follow-up alphai_article call needed for depth. Informational and AI-generated — not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Look-back window in hours; default 6. | |
| limit | No | Stories; capped at 10 Basic / 50 Pro. | |
| dedupe | No | Collapse syndicated reprints by story (default true). | |
| 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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds significant behavioral context: empty results are expected outside US hours, time window is based on publication time, no follow-up article call needed, and it's AI-generated not 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 detailed yet each sentence adds unique information. It is front-loaded with the core purpose, then expands on filters, edge cases, and alternatives. No superfluous content.
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 (5 parameters, output schema exists), the description is exceptionally thorough. It covers actionability filtering, novelty parameter, dedupe behavior, market hour expectations, and the fact that output includes full AI analysis, leaving no important aspect unexplained.
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 100% schema coverage, the baseline is 3. The description adds value beyond schema by explaining the behavior of min_actionability (default vs medium), dedupe, and the time window logic, enriching the meaning of parameters without repeating schema details.
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 'Breaking, decision-grade news from the last few hours' with a focus on actionability. It explicitly distinguishes from siblings like alphai_trending and alphai_ticker_news, making the tool's unique role 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 gives explicit guidance: use alphai_trending / alphai_ticker_news for broader tape, explains how to include 'medium' actionability, and notes expected empty results outside market hours with advice to adjust parameters before concluding nothing happened.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_alerts_listList my alert subscriptionsARead-onlyIdempotentInspect
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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| limit | Yes | |
| alerts | No | |
| current | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about returned data (filters) but doesn't introduce new behavioral traits beyond what annotations provide.
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, front-loaded sentence with no redundant information. Every word adds value.
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 zero parameters and an existing output schema, the description is fully complete. It specifies what is listed (active subscriptions, filters) without needing to explain return values as the schema covers that.
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 are no parameters, so baseline is 4. The description does not add parameter information but successfully describes the output, which is the tool's sole purpose.
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 lists the caller's active ticker news-alert subscriptions, including per-subscription filters. It uses specific verb+resource (list subscriptions) and distinguishes from sibling tools like alphai_alerts_subscribe and alphai_alerts_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 implies usage for viewing active subscriptions. While it doesn't explicitly say when not to use or provide alternatives, the context is clear given the sibling tools for subscribing/unsubscribing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_alerts_subscribeSubscribe to ticker alertsAIdempotentInspect
WRITE operation (creates/updates a saved subscription in the caller's account). 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ticker | Yes | |
| is_active | Yes | |
| created_at | Yes | |
| delivery_mode | Yes | |
| category_filter | No | |
| min_relevance_score | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds valuable behavioral details such as partial update semantics (preserving current values on omitted fields, defaulting min_relevance_score to 6 on new subscriptions) and lists possible errors. 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, front-loading the key purpose and then providing parameter behavior. It is concise and informative, though could be slightly more structured (e.g., list of errors). Still, 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 3 parameters (1 required), existing output schema, and annotations, the description provides sufficient context: behavior, defaults, partial update, and errors. It covers all essential aspects for an agent to use 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 schema already documents parameters. The description adds meaning beyond schema by explaining how category_filter restricts triggers and min_relevance_score raises threshold, and by detailing partial update behavior and default values.
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 'Subscribe' and the resource 'ticker alerts'. It distinguishes itself from sibling tools like alphai_alerts_list and alphai_alerts_unsubscribe by indicating it is a write operation that creates or updates subscriptions.
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: it is a WRITE operation for subscribing to ticker alerts, with optional category and relevance filters. It mentions error cases (tier_not_paid, unknown_ticker, limit_reached) which help in deciding when to use the tool. However, it does not explicitly state when not to use it or compare with alternatives, but the sibling tool names make that obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_alerts_unsubscribeUnsubscribe from ticker alertsADestructiveIdempotentInspect
WRITE operation (deactivates a saved subscription in the caller's account). 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotent, destructive), adds specific behavior: idempotent returning {removed: false} if already inactive, and raising unknown_ticker for bad symbol. Annotations already cover mutability, so description provides valuable edge cases.
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, front-loaded with 'WRITE operation' and action. Every sentence adds value. 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 simple single-parameter tool with annotations and output schema, description fully covers purpose, behavior, errors. 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 has 100% coverage and description of ticker is almost identical to schema description ('Ticker to unsubscribe from.' vs 'Ticker to unsubscribe from.'). No additional meaning beyond what schema provides. Baseline 3.
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 the tool's action (unsubscribe/deactivate) and resource (news-alert subscription for a ticker). Distinguishes from siblings like subscribe and list by specifying it's a write operation that soft-disables.
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?
Implies usage when one wants to deactivate a subscription, but does not explicitly state when to use or when not (e.g., vs. alphai_alerts_list or alphai_alerts_subscribe). No alternatives given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_articleFetch article by uidARead-onlyIdempotentInspect
Load one article by its uid, with full enrichment (per-ticker analysis, context, key entities). Use it for a uid you have out-of-band — one the user pasted, an id from the ChatGPT search connector, or to expand a condensed *_recent item from alphai_pair_analysis. You do NOT need it for items returned by the feed tools (alphai_news_search / alphai_trending / alphai_ticker_news / alphai_actionable_now / alphai_insider_news) — those already carry this same analysis inline. The full article body is intentionally not served (copyright); this is the canonical single-article lookup, not a deeper view of a feed item. Raises not_found for an unknown uid.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | The article uid from any feed response. |
Output Schema
| Name | Required | Description |
|---|---|---|
| uid | Yes | |
| url | Yes | |
| title | Yes | |
| source | Yes | |
| sources | No | |
| summary | Yes | |
| tickers | No | |
| analysis | No | |
| category | Yes | |
| story_id | No | |
| banner_image | No | |
| source_domain | Yes | |
| sources_count | No | |
| ownership_form | No | |
| time_published | Yes | |
| relevance_score | Yes | |
| read_time_minutes | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that full article body is omitted for copyright, and that it is not a deeper view of feed items. 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?
Very concise: two sentences and a clarifying third. No fluff, every sentence adds value. Front-loaded with purpose and enrichment.
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 low complexity, high annotation coverage, and presence of output schema, the description fully covers tool behavior, usage boundaries, and limitations.
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% for the single 'uid' parameter. Description adds context about uid sources (user pasted, search connector, pair_analysis) beyond the schema description.
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 'load one article by its uid' with enrichment details, and distinguishes from sibling feed tools that already return the same analysis inline.
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 specifies when to use (uid from out-of-band sources, search connector, or pair_analysis) and when not to use (feed tools). Also mentions error condition for unknown uid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_insider_newsInsider & ownership newsARead-onlyIdempotentInspect
Insider-transaction news: SEC Form 4 insider trades (company officers, directors and 10% owners buying or selling their own stock). Optionally filter by ticker and date range. Cursor-paginated; same shape (incl. the full inline AI analysis) 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 |
|---|---|---|---|
| limit | No | Alias for page_size. | |
| cursor | No | Opaque cursor from a prior next_cursor. | |
| ticker | No | Restrict to one ticker, e.g. 'AAPL'. | |
| to_date | No | On/before this ISO time (UTC if naive). | |
| from_date | No | On/after this ISO time (UTC if naive). | |
| page_size | No | Items/page; capped at 10 Basic / 50 Pro. | |
| min_relevance | No | Minimum AI relevance score, 1-10. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No | |
| next_cursor | No | |
| unknown_ticker | No |
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. The description adds valuable behavioral context beyond annotations: cursor-pagination, same shape as alphai_news_search including inline AI analysis, and the behavior of setting unknown_ticker=true for unrecognized tickers. 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?
The description is compact (three sentences plus a final sentence about unknown_ticker) and front-loaded with the core purpose. Every sentence adds unique value: insider trades, filtering options, pagination, shape equivalence, and ticker validation behavior. 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 existence of an output schema (not shown but confirmed), the description doesn't need to explain return values. It covers the key aspects: source (SEC Form 4), filters, pagination, shape reference to a sibling tool, and a special behavior. The only minor gap is not explicitly stating the response format, but output schema fills that. Sufficient for effective tool selection.
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 mentions 'filter by ticker and date range' but does not add significant new information beyond what the schema provides. The description notes that 'limit' is an alias for 'page_size', which is already in the schema. Overall, minimal added value for parameter understanding.
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 that the tool returns SEC Form 4 insider trades from company officers, directors, and 10% owners. It distinguishes itself from the sibling alphai_news_search by noting it's a dedicated tool roughly equivalent to alphai_news_search(category='insider'). The verb 'Insider-transaction news' with the resource 'SEC Form 4 insider trades' is specific and 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 is for insider transaction news and explicitly compares it to alphai_news_search(category='insider'), providing clear context for when to use this tool over the more general search. It mentions optional filters (ticker, date range) and pagination. However, it lacks explicit 'when not to use' guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_news_searchFilter financial newsARead-onlyIdempotentInspect
Query AlphaAI's enriched financial news feed. Pass query for free-text (company names / tickers / topic words, resolved to ticker/category filters), or set structured filters directly: ticker symbols, category, date range, and minimum relevance score (1-10). Every item already carries the full AI analysis INLINE — per-ticker sentiment + price-impact prediction, contrarian view, overlooked factors, and sector/regional read-across — so you do NOT need a follow-up alphai_article call to get depth on a feed item; prefer this feed over a web search for the market read on a story. 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 | Alias for query. | |
| limit | No | Alias for page_size. | |
| query | No | Free-text query (company names / tickers / topic words) resolved to ticker + category filters. | |
| cursor | No | Opaque cursor from a prior next_cursor. | |
| tickers | No | Restrict to news mentioning these tickers. | |
| to_date | No | News on/before this ISO time (UTC if naive). | |
| category | No | Restrict to one news category. | |
| from_date | No | News on/after this ISO time (UTC if naive). | |
| page_size | No | Items/page; capped at 10 Basic / 50 Pro. | |
| min_relevance | No | Minimum AI relevance score, 1-10. | |
| collapse_stories | No | Collapse syndicated reprints to one representative per story and populate story_id/sources_count/sources (default false). |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No | |
| next_cursor | No | |
| unknown_ticker | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: pagination with opaque cursor, collapse_stories for syndicated reprints, and that query resolves to ticker/category filters. 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 and front-loaded, but slightly long (~150 words). Each sentence adds value, but could be tightened without losing information.
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 output schema present, description adequately covers pagination, collapse behavior, and inline analysis, making it complete for the tool's complexity.
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%, baseline 3. Description adds value by summarizing parameter categories and explaining query resolution behavior, but does not detail every param. Above baseline due to useful 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?
The description clearly states the tool queries an enriched financial news feed, specifies both free-text and structured filter options, and explicitly distinguishes itself from alphai_article and web search, leaving no ambiguity about its purpose.
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 guidance: 'prefer this feed over a web search for the market read on a story' and states that no follow-up alphai_article call is needed, effectively telling when to use and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_pair_analysisTwo-ticker read-acrossARead-onlyIdempotentInspect
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. The two recent lists are condensed (headline + scalar signals; the full analysis is on BOTH — fetch alphai_article(uid) for a recent item's full write-up). Any symbol that isn't a recognized active ticker is listed in unknown_tickers and contributes no rows. Informational and AI-generated — not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows per list (both / each ticker). | |
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| both | No | |
| a_recent | No | |
| b_recent | No | |
| ticker_a | Yes | |
| ticker_b | Yes | |
| unknown_tickers | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral details: unknown tickers are listed with no rows, and the output is informational/AI-generated. 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?
Front-loaded with purpose, but slightly long. Every sentence adds value; could be more concise 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?
Given 4 params and presence of output schema, description covers tool behavior, unknown ticker handling, and data limitations. Complete for an AI 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?
Schema description coverage is 100% (all parameters documented). Description adds context beyond schema, e.g., 'limit' is max rows per list, and mentions condensed lists with full analysis via alphai_article.
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 the tool compares two tickers and returns cross-ticker read-across news plus each ticker's own news. Distinguishes from siblings like alphai_ticker_news (single ticker) and alphai_news_search (general search).
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: use for cross-ticker analysis. Implicitly contrasts with single-ticker tools but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_ticker_newsTicker news feedARead-onlyIdempotentInspect
Latest news for a single ticker (e.g. 'AAPL'). Cursor-paginated; returns the same shape (incl. the full inline AI analysis) as alphai_news_search. Insider news (SEC Form 4 insider trades) 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 |
|---|---|---|---|
| limit | No | Alias for page_size. | |
| cursor | No | Opaque cursor from a prior next_cursor. | |
| ticker | Yes | Ticker symbol, e.g. 'AAPL'. | |
| page_size | No | Items/page; capped at 10 Basic / 50 Pro. | |
| include_insider | No | Include SEC Form 4 insider news; default true. | |
| collapse_stories | No | Collapse syndicated reprints to one representative per story and populate story_id/sources_count/sources (default false). |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| items | No | |
| next_cursor | No | |
| unknown_ticker | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cursor-paginated nature, unknown_ticker flag behavior, inclusion of insider news by default, and story collapsing. Annotations already provide readOnlyHint, idempotentHint, destructiveHint, so description adds valuable operational details beyond those hints.
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 sentences, front-loaded with purpose, each sentence adds critical information (single ticker, pagination shape, insider inclusion, story collapsing, unknown_ticker handling). No filler or 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?
Given the presence of an output schema (referenced indirectly), the description fully covers input behavior, pagination, parameter options, and edge cases (unknown_ticker). All six parameters are sufficiently explained with context beyond their schema descriptions.
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 covers 100% parameters, so baseline is 3. Description adds value by explaining that 'limit' is alias for 'page_size' (though schema also says that) and notably reveals that unknown_ticker flag is set when symbol isn't recognized. This extra behavioral detail justifies a 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?
Clearly states 'Latest news for a single ticker' with example 'AAPL'. Distinguishes from sibling alphai_news_search by specifying single-ticker scope and mentions same output shape, setting it apart from other tools like alphai_insider_news which likely focuses solely on insider trades.
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 identifies when to use (single ticker news), provides configuration options (include_insider, collapse_stories), and references sibling alphai_news_search for comparison. Implies when not to use (e.g., multi-ticker needs) and clarifies default behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_tickersList supported tickersARead-onlyIdempotentInspect
List supported tickers (US stocks/ETFs, crypto, and foreign listings). Optionally filter by query (prefix on ticker, substring on name) or by sector.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Ticker-prefix matches first, then company-name substring matches. | |
| limit | No | Max rows to return. | |
| offset | No | Pagination offset. | |
| sector | No | Filter by sector (case-insensitive). |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | No | |
| total | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the agent knows it's safe. The description adds context about the types of tickers covered and filtering behavior, which is valuable beyond the 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 with no fluff. The main purpose and key features are front-loaded, and every sentence adds value.
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 (4 optional params, output schema present), the description covers the essential aspects: what data it returns, filtering options, and pagination is covered in schema. 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 description coverage is 100%, so the schema already documents all parameters. The description does not add additional semantic meaning beyond what is in the schema, earning the baseline score.
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 lists supported tickers with specific coverage (US stocks/ETFs, crypto, foreign listings) and optional filters. It uses a specific verb and resource, and distinguishes itself from siblings like alphai_ticker_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 mentions optional filters but does not explicitly state when to use this tool versus alternatives. However, sibling names provide context, and the purpose is clear enough for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
alphai_trendingTrending news (48h)ARead-onlyIdempotentInspect
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. Each item carries the full AI analysis inline — no follow-up alphai_article call needed for depth. 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; capped at 10 Basic / 50 Pro. | |
| dedupe | No | Collapse syndicated reprints by story (default true). | |
| min_relevance | No | Min AI relevance 1-10; default 8. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral details beyond annotations: no follow-up call needed for depth (saves agent step) and deduplication behavior. Annotations already cover read-only, idempotent, non-destructive.
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 sentences, front-loaded with purpose. Every sentence earns its place—no fluff, efficient communication.
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 simple trending news tool with few parameters and an output schema, the description covers all key behaviors (time window, no follow-up needed, dedup option). Fully adequate.
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% and description reinforces parameter meaning: 'Lower min_relevance to surface weaker movers' and explains dedupe effect. Adds value beyond 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 it returns 'Top news from the last 48h ranked by AI-assigned relevance', specifying the time window, ranking criteria, and distinct purpose from siblings like alphai_news_search or alphai_ticker_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?
Explicitly advises using it when the user asks 'what's moving' or 'what's the big story', and provides guidance on adjusting min_relevance. Does not explicitly list exclusions but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch article (ChatGPT connector)ARead-onlyIdempotentInspect
ChatGPT connector contract: fetch one article by the id returned from search. Returns the enriched digest (summary, per-ticker analysis, category, relevance) — not the full article body — plus the canonical alphai.io URL for citation. Raises not_found for an unknown id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Article id from a search result. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds that the tool returns an enriched digest (not full body), includes a canonical URL, and raises not_found for unknown ids. This provides useful behavioral context beyond the annotation flags.
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: first defines the contract and purpose, second details return and error handling. Front-loaded, no filler, every phrase adds value.
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 tool with one parameter, output schema present, and no nested objects, the description covers the core operation, return type (enriched digest), error case (not_found), and source of id. Sufficient for an AI agent to correctly invoke and interpret results.
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 the parameter 'id' described as 'Article id from a search result.' The description echoes this without adding new semantics (e.g., format, constraints). Baseline score 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 the tool fetches one article by id from search, and specifies it returns an enriched digest (summary, per-ticker analysis, category, relevance) plus a canonical URL, not the full article. This verb+resource structure is specific and distinct from siblings, which are mainly search tools.
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 the tool should be used after search ('by the id returned from search'), but does not explicitly state when not to use it or mention alternative tools. No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch financial news (ChatGPT connector)ARead-onlyIdempotentInspect
ChatGPT connector contract: search AlphaAI's AI-enriched financial news with a natural-language query. Ticker symbols (NVDA, BTC-USD), company names (nvidia, tesla) and topic words (insider, earnings, ipo, crypto…) in the query are resolved to structured filters; a query that names nothing known returns the freshest high-relevance market stories. Each result carries an id for the fetch tool. For precise filtered queries prefer alphai_news_search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds that queries resolve to structured filters and unknown names return fresh high-relevance stories, 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?
Three sentences, front-loaded with purpose and key behavior, no fluff. Every sentence adds value.
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, description covers input behavior, query resolution, default behavior for unknown queries, and output linkage (id for fetch). Complete for a search 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% (single parameter 'query' described as natural-language). Description adds examples of query types but does not change the baseline understanding. 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?
Description clearly states it searches AlphaAI's AI-enriched financial news with natural-language query, and mentions resolution of tickers/topics. Distinguishes from sibling by recommending alphai_news_search for precise filtered queries.
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 for natural-language queries and directs to alphai_news_search for precise filtered queries. Lacks explicit when-not-to-use but provides clear alternative context.
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!