AlphaAI

Fetch article by uid

alphai_article

Read-onlyIdempotent

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. ONE exception: on an SEC earnings filing (source_type sec_form8k or sec_form6k) this tool adds earnings, AlphaAI's structured read of the filing with every figure checked against the filing text, which the feed tools never populate. To go from a ticker straight to those reads, use alphai_earnings instead. 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`uid`	Yes	The article uid from any feed response.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`uid`	Yes
`url`	Yes
`title`	Yes
`source`	Yes
`insider`	No
`sources`	No
`summary`	Yes
`tickers`	No
`analysis`	No
`category`	Yes
`earnings`	No
`story_id`	No
`created_at`	Yes
`source_type`	No
`banner_image`	No
`source_domain`	Yes
`sources_count`	No
`ownership_form`	No
`time_published`	Yes
`relevance_score`	Yes
`read_time_minutes`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed5 schema fields changedSep 6, 2026

addedOutput schema / properties / created_at
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / earnings

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / insider

Added value: +{
+  "anyOf": [
+    {
+      "description": "Structured SEC Form 4 event block (``alphai_insider_news`` items only).\n\nAggregate of the news row's whole transaction group — same semantics as the\nREST ``/api/news/insider/`` block (openapi.yaml: ``InsiderEvent``): shares and\nvalue are GROUP sums (a 10b5-1 ladder is one event), ``avg_price_usd`` is\nvalue-weighted over priced tranches, ``is_10b5_1`` is the group OR, the\nlast fill dates the event. ``side`` is the signal label: buy (P) / sell (S)\n/ other (everything else, incl. D — sale to issuer, a buyback/redemption,\nnot an open-market disposition); the raw ``transaction_code`` rides along.\nMoney/share fields are decimal STRINGS (\"25000\", \"187.32\") — flat, precise,\nschema-simple; null when the filing prices no tranche.\n\n``filed_at`` is when EDGAR accepted the filing and ``late_filing`` marks the\nones that missed the SEC's two-business-day deadline; the rule lives in\n``_is_late_filing`` in ``repository.py`` (ported from the backend's\n``apps.insider.services.filing_lateness``). Field reference for both\nsurfaces: ``backend/openapi.yaml`` (``InsiderEvent``).",
+      "properties": {
+        "avg_price_usd": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "filed_at": {
+          "type": "string"
+        },
+        "insider_name": {
+          "type": "string"
+        },
+        "insider_title": {
+          "type": "string"
+        },
+        "is_10b5_1": {
+          "type": "boolean"
+        },
+        "is_director": {
+          "type": "boolean"
+        },
+        "is_officer": {
+          "type": "boolean"
+        },
+        "is_ten_percent_owner": {
+          "type": "boolean"
+        },
+        "late_filing": {
+          "type": "boolean"
+        },
+        "shares": {
+          "type": "string"
+        },
+        "side": {
+          "type": "string"
+        },
+        "total_value_usd": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "transaction_code": {
+          "type": "string"
+        },
+        "transaction_date": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "side",
+        "transaction_code",
+        "shares",
+        "is_10b5_1",
+        "insider_name",
+        "insider_title",
+        "is_officer",
+        "is_director",
+        "is_ten_percent_owner",
+        "transaction_date",
+        "filed_at",
+        "late_filing"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / source_type

Added value: +{
+  "default": "",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "uid",
-  "title",
-  "url",
-  "source",
-  "source_domain",
-  "summary",
-  "category",
-  "relevance_score",
-  "time_published"
-]New value: +[
+  "uid",
+  "title",
+  "url",
+  "source",
+  "source_domain",
+  "summary",
+  "category",
+  "relevance_score",
+  "time_published",
+  "created_at"
+]

First observedJun 17, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, so the description only needs to add context beyond that. It does: the full article body is intentionally not served due to copyright, the tool raises not_found for unknown uids, and it populates `earnings` for SEC filings. These are meaningful behavioral disclosures not present in structured metadata.

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 dense and somewhat long, but each sentence earns its place: purpose, usage scenarios, non-usage cases, the SEC exception, the copyright limitation, and the not_found error. The only slight redundancy is the closing phrase 'canonical single-article lookup, not a deeper view of a feed item,' which partially restates earlier points, but it does reinforce the distinction effectively.

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, the description covers all essential operational context: how to obtain a valid uid, when to avoid the tool, the one exception where it adds unique value (SEC earnings), behavior on unknown uids, and the copyright-driven omission of the full body. The presence of an output schema relieves it from documenting return fields, so nothing necessary is missing.

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%, so the schema already documents the uid parameter. The description adds real value by characterizing which uids are appropriate (user-pasted, search-connector ids, condensed `*_recent` items) and which are unnecessary (feed tool items already contain the analysis inline). This goes beyond the schema's generic 'any feed response' phrasing and gives the agent pragmatic selection 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 opens with a specific verb and resource: 'Load one article by its uid, with full enrichment.' It then distinguishes itself from siblings by declaring itself 'the canonical single-article lookup, not a deeper view of a feed item,' which clearly separates it from the feed tools.

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 gives explicit when-to-use scenarios: out-of-band uids, user-pasted ids, ChatGPT search connector ids, and expanding `*_recent` items from alphai_pair_analysis. It also explicitly states when NOT to use it (feed tool items already carry the analysis inline), names the exception (SEC filings add `earnings`), and points to alphai_earnings as the alternative for ticker-to-earnings lookups.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AlphaAI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation3/5

Multiple news feed tools (alphai_actionable_now, alphai_trending, alphai_macro, alphai_ticker_news, alphai_news_search, alphai_insider_news, and search) overlap in purpose, so an agent could pick the wrong one by name alone. The detailed descriptions clarify each tool's window, scope, and filtering, but the set still relies heavily on reading those descriptions to avoid misselection.

Naming Consistency3/5

Most tools share the alphai_ prefix and snake_case, but there is no consistent verb_noun pattern: alphai_alerts_subscribe and alphai_news_search are verb phrases while alphai_ticker_news, alphai_macro, and alphai_calendar are noun phrases. The un-prefixed connector tools search and fetch add a further deviation, making the naming readable but mixed.

Tool Count3/5

At 16 tools, the set is at the heavy end and includes several near-duplicates: alphai_news_search vs search, alphai_article vs fetch, and alphai_insider_news vs alphai_news_search(category='insider'). The domain is broad enough to justify many specialized feeds, but the redundancies make it feel padded.

Completeness4/5

The toolset covers news discovery, search, article retrieval, alerts lifecycle, macro calendar, earnings reads, ticker metadata, and pair comparisons, so agents can complete most workflows. Minor gaps remain, such as no story-level detail endpoint and no broader user-account or watchlist management beyond alerts.

Fetch article by uid

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources