alphai-news

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.5/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![alphai-mcp MCP server](https://glama.ai/mcp/servers/makeev/alphai-mcp/badges/card.svg)](https://glama.ai/mcp/servers/makeev/alphai-mcp)

Score Badge

Copy to your README.md:

[![alphai-mcp MCP server](https://glama.ai/mcp/servers/makeev/alphai-mcp/badges/score.svg)](https://glama.ai/mcp/servers/makeev/alphai-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/makeev/alphai-mcp'

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