AlphAI

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, a news uid from alphai_insider_clusters, 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. SEC rows carry the same structured block the feed tools serve: insider on a Form 4 (source_type sec_form4: shares, avg_price_usd, is_10b5_1, filed_at...) and filing on an 8-K. ONE addition over the feeds: on an SEC earnings filing (source_type sec_form8k or sec_form6k) this tool adds earnings, AlphAI'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
`filing`	No
`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
`search_match`	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.

Changed1 schema field changedSep 26, 2026
- addedInput schema / properties / uid / maxLength
```
Added value: +64
```

Changed1 schema field changedSep 23, 2026

addedOutput schema / properties / search_match

Added value: +{
+  "anyOf": [
+    {
+      "description": "Per-item evidence from the text path: ``score`` orders the page (cover\ndensity × recency; comparable within one response, not a probability),\n``terms_matched`` is set in broadened mode, ``context`` marks the matched\nwords in the summary with ``**``.",
+      "properties": {
+        "context": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "score": {
+          "type": "number"
+        },
+        "terms_matched": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "required": [
+        "score"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changed1 schema field changedSep 22, 2026

addedOutput schema / properties / filing

Added value: +{
+  "anyOf": [
+    {
+      "description": "Structured SEC 8-K filing block (``source_type == \"sec_form8k\"`` items on\nthe news tools).\n\nA read-only projection of the 8-K sidecar\n(``apps.data.models.EightKEventModel``) — same fields and semantics as the\nREST ``/api/news/`` block (openapi.yaml: ``EightKFiling``): ``items`` is\nevery item code the filing carries (the ``item`` filter matches any of\nthem; empty for a header-only filing), ``primary_item`` the one that drove\nthe category, ``accession_number`` the id to cite, ``filed_at`` EDGAR's\nacceptance time, ``event_date`` the filing's own date of report and\n``exhibit_url`` the press-release exhibit the summary was built from.\nDates are ISO strings like the insider block; empty sidecar strings are\n``null``, never ``\"\"``.",
+      "properties": {
+        "accession_number": {
+          "type": "string"
+        },
+        "event_date": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "exhibit_url": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "filed_at": {
+          "type": "string"
+        },
+        "items": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "primary_item": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "required": [
+        "items",
+        "accession_number",
+        "filed_at"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

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

A5/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses key behavioral traits: the article body is intentionally not served due to copyright, it is the 'canonical single-article lookup' not a deeper view, it adds earnings data on SEC filings that feed tools never populate, and it raises not_found for unknown uids. This is rich behavior context that annotations alone do not provide.

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 long but every sentence earns its place: it front-loads the core purpose, then apps usage sources, exclusions, alternatives, limitations, and error behavior in a logical, dense structure. There is no fluff or repetition; the semicolon-delimited list of source types is efficient.

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?

For a single-parameter lookup tool with an output schema, the description is complete: it covers what the tool returns, when to use it, when not to use it, alternatives, behavioral limitations (no article body, copyright), and error behavior. An agent has everything needed to invoke it 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?

Although the schema already describes uid as 'The article uid from any feed response,' the tool description adds substantial sourcing guidance: uids can come from user paste, the ChatGPT search connector, alphai_insider_clusters, or expanded *_recent items from alphai_pair_analysis. This helps the agent know exactly what values are valid and where to obtain them, far exceeding the schema's generic description.

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 clearly specifies what the tool returns and explicitly distinguishes it from feed tools that already carry the same inline analysis, so an agent can tell it apart from siblings without opening schemas.

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?

Usage guidance is explicit and comprehensive: it lists the sources of valid uids (user-pasted, ChatGPT search connector, alphai_insider_clusters, alphai_pair_analysis), explicitly states when the tool is NOT needed (feed tools already carry the analysis), and points to alphai_earnings as the alternative for ticker-to-earnings lookup. This leaves no ambiguity about when to invoke it.

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

All AlphAI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.